* Daniel Gultsch <[email protected]> [2015-06-10 07:01]: > However if the MAM capable client is the only client in the game it > will (with normal setups) regularly receive both the offline messages > and the messages downloaded from the MAM archive.
This is one of the specific aspects that I have in mind when proposing to "rethink message routing in the context of MAM". MAM and offline messages are duplicating the same functionality. Still, we can not get rid of one as long as not all clients support the other. > Is there a solution to this problem that can simply be solved by server > side configuration? My proposal would be to replace the offline messages on the server with the MAM-ID of the last delivered (or first undelivered, whatever the implementor sees fit) message from MAM. When a MAM-capable client connects and requests MAM/MAMSub, the server simply wouldn't deliver the offline messages to it, but would update that last_offline_mid property accordingly. To accomplish that, two requirements must be fulfilled: a) MAM will store the same messages as offline or a superset of them. This is probably easy to do, we just need to specify which messages go into MAM. b) We need to solve the race condition between opening a session (when the server starts delivering offline messages) and requesting MAMSub. This is very similar to the MAM download / MAMSub race condition and related to the possible MAM download / new incoming messages race condition. I think an interesting solution to all of these would be to replace/extend the <session> element, i.e. by adding a MAM namespace to it. With a separate MAM session type, the server would be aware of the changed routing rules, would implicitly MAM-subscribe the client and inhibit offline message delivery, in a consistent and atomic way. That would also allow the server to push MIDs / reflected messages / Carbons to the client for all client-generated messages, to update it with the according MIDs. > Will simply disabling offline message return all messages to the sender > even though they are stored in MAM? This is another interesting question. If a client has enabled MAM but is offline, no errors should be generated for new incoming messages, unless the MAM archive is over quota. I think this also holds true for yet unacked SM messages. The above solution (track last_offline_mid) should work for both scenarios, as long as all messages were sent to the bare JID. If messages were sent to the full JID, things start to become interesting. We might need to define MAM/offline-storage business rules for re-routing full-JID messages into the archive. Personally I'd go with only ever archiving bare-JID messages, and only use full-JIDs for ephemeral messages like CSN or OTR. However, as opposed to the radical suggestion for (b) above, this would be way too radical as it would break most existing clients. Georg -- || http://op-co.de ++ GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N ++ || gpg: 0x962FD2DE || o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+ || || Ge0rG: euIRCnet || X(+++) tv+ b+(++) DI+++ D- G e++++ h- r++ y? || ++ IRCnet OFTC OPN ||_________________________________________________||
signature.asc
Description: Digital signature
