*Theory of <thread/>* (or "What is meant by Thread ID")
The intention for <thread/> is to track a conversation across multiple <message/> packets. In theory, when someone starts a conversation with someone else, their client would specify a value for <thread/>. The value itself has no intrinsic meaning, but is simply a "marker" or "tracking number" (well, "tracking *string*"). When that someone else responds, they maintain the <thread/>. Ideally, each unique conversation would be a different thread. Taken to the extreme, multiple conversations between two people *could* be carried out, each with a different <thread/>.
*Practice of <thread/>* (or "What [many] current implementations actually do")
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. 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.
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.
- If it's missing, assume its part of the last conversation you had with the "to" side, if any.
Hope this helps,
- LW
Johannes Ernst wrote:
I'm trying to understand
1) what is meant by a "Thread ID"
2) what current implementations actually do.
As in:
<message ...>
<thread>some-thread-id</thread>
<body>...</body>
</message>
Judging from my "extremely" scientific sample-size of 1 (trial end error with Exodus ;-)), it seems to me that
- Exodus will "play back" whatever thread ID another client used to initiate a new conversation
- However, as soon as the chat window has been closed once, upon reopening it, it will generate a new thread ID.
I don't know what that means. In particular, because Exodus happily restores the content of the old window in the new window.
I thought maybe a different thread ID would indicate a different subject (could be shown graphically with a horizontal line or whatever), or that the conversation partner has closed their window temporarily, or ... but if thread id is basically unpredictable, I'd rather leave it alone?!?
And I don't know whether this is the "correct" behavior, or just something special about Exodus.
Any clarifications appreciated...
_______________________________________________
jdev mailing list
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jdev
_______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
