[JDEV] Thread id

[Tijl Houtbeckers]

"Matthew A. Miller" <linuxwolf at outer-planes.no-ip.com> wrote on 29-1-
2003 5:20:06: 
>
>Unfortunately, many clients never [properly] acknowledge the 
><thread/>, either for the start of a conversation or in maintaining it.
>  Because of this, clients like Exodus simply treat all messages 
>  between two 
>people [within a given amount of time] as part of the same 
>conversation. 

The problem with <thread/> is that it tries to force client makers into 
a UI-design decision. (multiple conversations with on resource). Not 
all clients want to do this and the <thread/> mechanism provides no 
good way of not doing this, and at the same time staying compatible 
with clients who do implement this. That raises the question of wether 
such a UI centric spec. should exist. 


>  Since Exodus tries to be true to the spec, it tries to use <thread/> 
>  for 
>conversations.  But since "compliant" clients can't rely on the other 
>side maintaining the (optional) <thread/>, it behaves as it does.

I don't know what exodus does, but my client usually just sends 
type="chat" without <thread/>. As soon as the other client sends a 
thread-id it does send one back, always the latest one the other client 
used. This provides the most compatability with other clients, but it's 
far from complete. I'm thinking about changing this behaviour though, 
for the reason below. 

>Maybe, some day in the [far?] future, when all clients properly use 
><thread/>, can look back at this and have a good laugh (or tell our 
>grandchildren how tough it was to use IM, what with more than one 
>protocol in use; uphill both ways in the snow and all that).  In the 
>meantime, the following would probably be a good way for your client 
>to behave:
>
>-  If you get a <thread/>, you should maintain it.
>-  If your client is starting the conversation, generate one.

I don't agree with you here. Just send a type="chat" without a thread-
id. Smart clients that *do* support threads will notice that your 
client does not. If your client has no use for thread-ids why generate 
them and use them? Threads only seen usefull to me for having multiple 
conversations with the same resource at the same time. 

Or do you use them to keep track of when a conversation starts and ends?
 For example.. when you close the window, and open it again, generate a 
 new threadid. Though I suppose in some cases this kind of information 
 could be usefull to the other client, the other client can't do 
 anything with this info, since it doesn't know whether the old thread 
 stopped and a new one started, or wether there are just two different 
 threads at the same time. If you want to properly use this you should 
 think about using/extendind event-notification for this. 

>-  If it's missing, assume its part of the last conversation you had 
>with the "to" side, if any.

If you don't give the user the ability to see the difference between 
messages from different threads and don't give the user the ability to 
choose wich thread to respond in (for example by having multiple chat 
windows for multiple thread-ids), you have no use for thread-ids. So in 
the perfect world you should *never* send them, and clients that do 
support them should see type="chat" messages without a threadid as a 
seperate thread, to wich they also send back no thread-id, instead of 
trying to generate a new one all the time. 

Maybe we'll be telling our grandchilderen about how desktop-focuced 
Jabber once used to be.. and how some clients tried to force certain UI 
features through the protocol even.. /me wonders if they'll know what a 
desktop is... 


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