Hi, I'd like to discourage message duplication. Transport and processing is not free. If you consider the impact on a service with several million users, you can see the outlines of the problem.
Further consider the entire de-duplication industry, one that operates at various levels of the OSI stack. The size of that market illustrates the importance of efficiency to the IT industry. If you can solve the problem with identifiers, checksums, and acknowledgements, there is strong motivation to do so. David From: Standards [mailto:standards-boun...@xmpp.org] On Behalf Of Daniel Gultsch Sent: Thursday, January 22, 2015 03:16 To: XMPP Standards Subject: Re: [Standards] XEP-0313 adding archive id to live incoming messages Hi Kevin, 2015-01-22 10:46 GMT+01:00 Kevin Smith <kevin.sm...@isode.com<mailto:kevin.sm...@isode.com>>: Older versions of the XEP had the server inject MAM UIDs (not to be confused with message stanza IDs, which they are not) into incoming stanzas in an effort to allow clients complete local copies of their archive without ever receiving a message twice. However, this didn’t work; there were edges (particularly around messages passing each other on the wire) where the client would end up with an incomplete copy of the archive. The current version of the spec doesn’t have it. If you want to do a full sync, you will indeed receive incoming messages addressed to your own client twice - once when you receive them via normal routing, and once when you next synchronise with the MAM archive. I don't care too much about actually receiving the message twice (I would still query the entire archive since the last time I have been online) I just want to be able deduplicate messages in my own local history. I see that they are still edges (for example with sent messages where I would have no way of knowing the archive id) but it would at least minimize the current effects with duplicate messages I'm seeing. Right now I'm trying to fake dedup by matching the body and the message id but that of course fails when my contacts clients don't set a message id. cheers Daniel ---------------------------------------------------------------------- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately by return email and delete the message and any attachments from your system.
