About threads, I missed some text in XEP-0136...
Peter Saint-Andre wrote:
> Alexander Tsvyashchenko wrote:
>> To be true, I think that this issue is out of the
scope of XEP-136 - I
>> would expect that <thread> behavior either
should be specified by
>> XEP-201 (or somewhere else) or left as
implementation-defined; on the
>> other hand, XEP-136, probably, should just take
into account <thread>
>> values and use them for its business like described
above.
>
> Agreed. So perhaps we need to say how threads are used
in archiving. I
> see that we've left that out so far.
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.
>> 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.
Peter
--
Peter Saint-Andre
https://stpeter.im/
|
