[JDEV] Thread id
thoutbeckers at splendo.com
Thu Jan 30 15:57:12 CST 2003
Nathan Walp <faceprint at faceprint.com> wrote on 30-1-2003 21:37:18:
>On Thu, Jan 30, 2003 at 09:51:27AM -0800, Johannes Ernst wrote:
>> BTW, I very much agree with Tijl Houtbeckers that if a client has no
>> way of setting / changing / displaying different values for
>> <thread/> it has no business sending values for it.
>I was led to believe that if a client didn't support threads, it should
>still send a <thread/> initially, and reply with the most recent thread
>it had received.
I don't see why it should send threads if it doesn't support threads.
For exmaple, let's say I have a client(1) that support threads and one
client(2) that does not.
The user of client(1) wants to start 2 threads, one on some personal
stuff and one for buisness:
he first sends a type="chat" with <thread>123</thread> and <body>how
are you?</body> then he sends a type="chat" with <thread>987</thread>
and <body>did you finish the report?</body>
user of client(2) responds after both messages are send. let's suppose
it replies with the most recent <thread/> it has received.
type="chat" with <thread>987</thread> and <body>I am fine thanks</body>
type="chat" with <thread>987</thread> and <body>no I still have to work
on the finance section</body>
As you can see the first message ends up in the wrong thread.
Futhermore there is no way client(1) can know client(2) does not
support threads. Only the user of client(1) in confronted (and annoyed)
Let's asume that all clients that support threats use them, and
*always* use them when starting a type="chat" conversation, and all
clients that do not support them, never use them.
The reply (with no <thread> in it at all) would give client(1) an
important hint that client(2) does not support threads. This is already
a lot better, and if client(2) started the conversation there wouldn't
be a problem at all. The only "gap" left however is that client(1) can
already start multiple threads before getting a reply from client(2),
leading to an akward UI situation.
BTW: Johannes, I agree that is was incorrect of me to state that it is
only a UI-feature. I think it was developed with a (specific) Desktop
UI in mind though..
Java/J2ME/GPRS Software Engineer @ Splendo
More information about the JDev