On 20 apr. 2012, at 10:32, Kevin Smith wrote:
> On Thu, Apr 19, 2012 at 6:01 PM, Matthew Wild <mwi...@gmail.com> wrote:
>> One solution I came up with was for an entity that relays and archives
>> messages to stamp the message with: <archived by="capulet.lit"
>> id="1234-5678"/> or <archived by="conference.jabber.org"
>> id="8765-4321"/>. I'd be interested in feedback on this idea.
>
> Yes, we need (archiving, rather than stanza) ids stamped on the
> archived stanzas.
>
>> However even <archived/> doesn't cover the case of the client knowing
>> the id of its *outgoing* messages. The server could echo them back
>> with <archived/>... but then things start to get a bit muddy.
>> The alternative is to not solve this, and clients should treat the MAM
>> archive as the canonical source of history - (therefore fetching
>> messages from the archive that have already been sent/received by it).
>> A waste of bandwidth if nothing else.
>
> You will only need to request (assuming you have carbons) on average
> less than a single message that's a duplicate, though - as IM is
> typically send a message/receive a message [yes, there are exceptions
> where this is potentially very untrue], and you will have the id of
> the message you received.
>
I've started implementing 0313 in libpurple/Adium, and I think
Matthew explained my concerns quite well.
Your suggestion assumes that once a client receives an incoming
message from the server, everything the client sent before that
moment was received by the server successfully (it makes sense to
require Carbons to do MAM, but lets assume that Stream Management is
not enabled). Suppose the last session ended with these two
messages, on a high-latency connection which got interrupted:
C:
<message id='12345' to='example.com'>
<body>Hello</body>
</message>
S:
<message id='9876' from='example.com'>
<body>Hey</body>
<archived id='abcde' by='example.com' />
</message>
If the client thinks message 12345 came before 9876, while the
server thinks it's the other way around, then requesting the archive
from abcde will duplicate message 12345.
On the other hand, if the client requests the archive starting from
abcde and does not receive message 12345, it can not know for sure
wether 12345 was even received by the server (the spec never
mentions it, but in my opinion being able to mark a message as "we
thought this message was sent, but the server never got it" is a
necessary part of synchronizing your logs).
Not a typical case, sure, but also not something that is very
unlikely to ever occur, and I think it's important to keep the
client's logs as consistent as possible.
I don't really have a good solution to propose, though. Replying to
every outgoing message with something that includes the UID it was
logged with could work, but it might add quite a bit of overhead.
Stream Management could help with the latter problem, but not the
former.
Regards,
Thijs
