[JDEV] Thread id

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) 
by this. 

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.. 

-- 
Tijl Houtbeckers
Java/J2ME/GPRS Software Engineer @ Splendo
The Netherlands