On 11.05.2015 17:25, Brian Cully wrote: > In implementing MAM in clients there can be a case where MAM results > contain duplicates of already seen messages. In order to prevent such > duplication, the MAM ID for a stanza would need to appear on a newly > generated non-MAM stanza. > > As background, imagine a client which, when it receives a new stanza > from a server, presents a view that renders the new stanza and then queries > MAM to provide a chat history between two JIDs. When the JID1 sends a message > to JID2 it is logged in the MAM store and forwarded on to JID2, JID2 then > requests MAM results for JID1, returning the last 50 messages, which would inc lude the stanza that indirectly generated the MAM request, leading to two copies of the stanza in the message view between JID1 and JID2.
I'm not sure if I would MAM to mandate that the client's XMPP server has to inject a unique (within the scope of the users server and MAM archive) message ID into the message stanza that is going to get delivered to the client. The "inject id" solution is also not ideal. What if there where messages between the last time the client retrieved the archive and the now received message (containing a unique message/MAM ID)? Think especially of a multi-client/session scenario. I guess what I would do if I had to implement a client: 1. Retrieve message stanza 2. Display message in UI 3. Query MAM archive for messages since the last query 4. Update the UI: Append all messages received since the start of 3. to the MAM query result of 3. and show the resulting messages in the UI. From there on you could just display incoming messages in the UI without querying the MAM archive. Of course there is a possible race condition which could lead to messages getting displayed twice, but at least you don't loose messages. - Florian
signature.asc
Description: OpenPGP digital signature
