Peter,
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.
