[Standards] MAM IDs

Kevin Smith kevin at kismith.co.uk
Mon Feb 17 11:51:14 UTC 2014


On Mon, Feb 17, 2014 at 11:42 AM, Thijs Alkemade <thijs at xnyhps.nl> wrote:
>
> On 17 feb. 2014, at 12:02, Kevin Smith <kevin at kismith.co.uk> wrote:
>
>> On Mon, Feb 17, 2014 at 10:55 AM, Thijs Alkemade <thijs at xnyhps.nl> wrote:
>>>
>>> On 17 feb. 2014, at 11:26, Kevin Smith <kevin at kismith.co.uk> wrote:
>>>
>>>> In MAM, stanzas stored get stamped with a MAM ID by the entity that
>>>> stored them, and entities receiving them then receive this.
>>>>
>>>> So a general question - are these useful? Are clients going to ignore
>>>> them and just request all history since they last requested it anyway?
>>>>
>>>> /K
>>>
>>> Because querying by date range is unreliable, and should be avoided wherever
>>> possible. The client's and the server's clock could be minutes apart and even
>>> if they were synchronized then multiple messages arriving in the same second
>>> can lead to difficult edge cases.
>>
>> Yes, I'm not suggesting that querying by timestamp is a generally
>> sensible thing.
>>
>>> I'd much rather query by the UUID injected into a message than by the
>>> approximate datestamp.
>>
>> What are you querying for, and how are you using the injected ID? I
>> previously thought the ID injected into the stream would be useful,
>> but having now thought of how smart a client has to be to make use of
>> it (needs to query MAM on login, enable carbons, use 198-acks in some
>> slightly convoluted way to tie up outgoing messages with the incoming
>> ones to sort out ordering as the server archive saw it...), I'm less
>> convinced. I could become convinced again.
>>
>> /K
>
> I only have a partial implementation of MAM, but what it did was: if the last
> message handled was incoming, store the injected UUID. If it was outgoing,
> store its timestamp instead. On the next login, use the UUID or timestamp to
> query for new messages.
>
> I realize now that this isn't perfect, as it uses the client's view of the
> ordering of the last incoming and last outgoing message, which can differ from
> the server's view. Is this the reason you think the UUIDs are unnecessary?

I'm not necessarily saying they /are/ unnecessary, but I'm asking the
question, yes.

I think it's very hard without a lot of client smarts (and I think it
strictly requires 198 acks to correlate the timing, and even then
makes assumptions about the server's handling of MAM that might not be
true) to do anything useful with the incoming ID for the sake of
syncing local history. The model I think most clients will go with is
either to do something that doesn't quite work right in poor
conditions, like the timestamp stuff you suggest, or will simply not
try to correlate local and remote history and will periodically ask
the server for a 'manual' sync since the last manual sync point. I'm
wondering if I'm wrong :)

(And the reason I'm wondering is that the IDs could significantly
increase the complexity of a server implementation in some cases, as
it modifies all passing message stanzas, so if it's not needed getting
rid of it could be useful)

/K



More information about the Standards mailing list