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" <[EMAIL PROTECTED]> 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.I don't agree with you here. Just send a type="chat" without a thread-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.
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 [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
_______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
