[JDEV] Thread id

[Johannes Ernst]

I'm not sure that <thread/> is an entirely GUI-centric feature.

I admit It is a little weird because it is different from all other 
threading mechanisms that I'm aware of. E.g. newsgroups threads.

A Jabber <thread/> is basically a "bag" that collects messages, 
unordered, and says "these messages are all in the same bag".

A newsgroup thread, on the other hand, is implicit: each message 
carries a "pointer" to a message that this is a response to. To find 
out which messages belong to a thread, one has to traverse all the 
pointers. But the beneficial side effect is that one gets the 
hierarchical structure we all love/hate.

I think in either case, there are, or could be clear semantics:
  - "All of these messages belong to the same thread" (aka topic, to use 
a common definition of "thread" although it is not clear from the 
Jabber docs whether this definition of "thread" is actually what it 
meant in the Jabber context)
  - "This message responds to that message".
Both can be used to do communications pattern analysis, for example, 
and lots of things of that nature, which has nothing to do with GUIs.

I suggest:
1) someone provide a clear definition of what Jabber means by "thread" 
in the future. Insert into all relevant docs, or drop the tag because 
no one agrees what it means. It's also underdefined because it is not 
clear whether two threads with the same Thread ID are the same or 
different threads if to/from are different, or if there is a year 
between messages in the same thread or such.
2) Think about providing a way of saying "this message responds to that 
message" in the future. Which may be considered to obsolete <thread/> 
although it might not.

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.

On Wednesday, January 29, 2003, at 06:07 AM, Tijl Houtbeckers wrote:

> "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
>
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev
>