"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. >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 [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
