[Standards] XEP-136 and XEP-59 implementation comments: threading

Alexander Tsvyashchenko lists at ndl.kiev.ua
Tue Mar 25 16:18:23 UTC 2008


> About threads, I missed some text in XEP-0136...

... skipped ...

> Right now XEP-0136 says:
> ***
> If an opaque thread ID (found in the <thread/> children of the
> <message/> elements whose content is stored in the collection) is
> associated with the conversation then it MUST be specified with a
> 'thread' attribute.
> ***
> So I think the ThreadID is already being incorporated already.

Ok, but "parent" linking for collections still needs to be added to  
XEP-136 if you agree with the approach we've discussed.

>>> So, for me it looks like the following could be specified in XEP-136:
>>> 1) If no <thread> element exist, server may use its own
>>> implementation-defined strategies for mapping messages and conversations
>>> to collections and also may treat resources in implementation-defined way.
>>> Maybe some heuristic can be suggested such as the one I described in my
>>> first letter for "conversations tracking", but I doubt anything 100%
>>> reliable can be proposed.
>>> 2) If <thread> element is present, the mapping is exactly 1 <-> 1 (one
>>> thread element to one collection). If "parent" attribute is present for
>>> thread - the link should be created of type "parent" to the appropriate
>>> collection.
>> That seems reasonable.
>>> Resources can be treated as follows: when receiving first message with
>>> full JID it's allowed to overwrite previous bare JID of collection by
>>> new, full JID; if previous JID was already full and the new one is also
>>> full, and differs from the previous one - assume that we have
>>> "multi-resource" case, modify collection's JID to bare one and forbid
>>> all its further overwrites.
>> That, too, seems reasonable.
> I think those points belong in the implementation notes.

Hm, I would say that enforcing 1 <-> 1 mapping between  
threads/collections and the requirement to respect "parent" link might  
be considered as parts of the specification, no? Although the  
requirement to have "thread" attribute, as it's written in XEP-136,  
already implies 1 <-> 1 mapping, I would say it's better to state that  
explicitly to avoid any ambiguities.

I agree that the other things are more up to the implementation -  
though I'd prefer having these notes available somewhere if I had  
started working on mod_archive_odbc now, as they would save me some  
time, so I think they still might be useful to other implementors.

Good luck!                                     Alexander

This message was sent using IMP, the Internet Messaging Program.

More information about the Standards mailing list