[Standards] MAM IDs
thijs at xnyhps.nl
Mon Feb 17 11:42:40 UTC 2014
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?
>> 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.
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?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
More information about the Standards