On Mon, Jan 26, 2015 at 1:08 PM, Kevin Smith <kevin.sm...@isode.com> wrote:
> Please bottom-post on this list. > > On 26 Jan 2015, at 11:20, Piotr Nosek <piotr.no...@erlang-solutions.com> > wrote: > >> > >> On Thu, Jan 22, 2015 at 2:47 PM, Kevin Smith <kevin.sm...@isode.com> > wrote: > >> On 22 Jan 2015, at 13:24, Georg Lukas <ge...@op-co.de> wrote: > >> > > >> > * Kevin Smith <kevin.sm...@isode.com> [2015-01-22 14:14]: > >> >>> How would you deduplicate a mix of messages received normally and > MAM > >> >>> messages? Are you supposed to delete all normal messages when > syncing up > >> >>> with MAM? > >> >> Yep. > >> > > >> > Hmm. My gut feeling is that I don't particularly like that approach. > >> > Maybe we can really deprecate it with the unique-id idea. > >> > >> As I said earlier - if someone can come up with an alternative that > works (in the edge cases, not just the obvious single-client case), I think > speccing it would be great. No-one’s come up with such a proposal yet. > > But what are these edge cases actually? Can anyone write an example, a > clear scenario that is problematic when using server-side IDs? > > A few examples (between server and client) of what happens if you try to > use the local archive on a client to fill in gaps in received server > archives (i.e. to not fetch server archives for periods the client was > online). These are addressible, to different degrees, with sufficient > amounts of client smarts, but not (I believe) all. The list of edge cases > was longer than this, but these are the ones I can trivially remember: > > 1 server sends messageA > 2 client sends messageB > 3 client receives messageA > 4 server receives messageB > > Client has the archive out of order > > I believe that the order of messages A & B is not so relevant, since it is unlikely they are question and answer (we are observing race condition here). The order will be mixed until next sync, because the only archive ID the client has, are the ones from the messages received. So if the communication is interrupted at this point, the client will reconnect, query MAM for messages after messageA and will learn that from server perspective messageB should be after messageA, so the client can patch the local archive. If the conversation continues, the incorrect order will most likely persist in device memory but then again - how harmful for user experience it could probably be? > 1 server sends messageA > 2 client sends messageB > 3 client receives messageA > 4 client disconnects > > Client has a message in its archive that was never delivered. > > I believe XEP-0198 can deal with it and with SM enabled, the client shouldn't store the message in archive until the ack is received. > 1) client sends messageA > 2…26) client sends messageB…messageZ > 3) session ends > > The client has to do a full sync anyway, because it doesn’t have IDs for > any of its sent stanzas. > > /K I can't think of a way to definitely solve this right now but is it such a frequent case that you will send tons of messages to someone without a single answer and then reconnect repeatedly? Anyway I think it is essential to have some ID assigned by server (at least) in MAM. Even if clients would add proper IDs to the stanzas, the server might prefer an optimized ID types to enhance archive lookups, like a guarantee for them to be non-decreasing.
