[JDEV] Thread id

Matthew A. Miller linuxwolf at outer-planes.no-ip.com
Tue Jan 28 22:20:06 CST 2003


Asking for theory and asking for practice can yield two different 
results (-:  This is as I understand it, although those more steeped in 
user-user message passing feel free to correct me...

*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
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev






More information about the JDev mailing list