On Mon, Feb 17, 2014 at 11:42 AM, Thijs Alkemade <[email protected]> wrote: > > On 17 feb. 2014, at 12:02, Kevin Smith <[email protected]> wrote: > >> On Mon, Feb 17, 2014 at 10:55 AM, Thijs Alkemade <[email protected]> wrote: >>> >>> On 17 feb. 2014, at 11:26, Kevin Smith <[email protected]> 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
