On Sun, 27 Sep 2020 at 16:46, Holger Weiß <[email protected]> wrote:
> When opening a new session, MAM clients might want to use the > most-recent known XEP-0359 stanza ID to sync messages. One problem they > face is that there's no way to figure out the stanza ID of outgoing > messages, short of actually querying them back from MAM. Therefore, a > common workaround is to use the stanza ID of the most-recent _incoming_ > message and then de-dup any outgoing messages returned from MAM. > > I think it would be good to find a better solution. OK, just out of curiosity, why? The case this is for is when the last N messages of a previous session of the same client are all outgoing messages from that session, and therefore the last N messages will be returned from a subsequent MAM query. Note that we always know the stanza id (the one on the stanza itself, not the MAM id which we annoyingly call the Stanza ID), and so a well-design client will be able to recognise it later (and may well have further ways to de-duplicate the message). The implication here is that the MAM messages returned are redundant data, and what we're looking to do is optimize for that case. However, for all outgoing messages from a session which are not the last messages of that session, any "ack" purely to contain the MAM id is also redundant. So my general view is that if the redundancy of the solution is worse than the redundancy of the problem we're trying to solve, that suggests we shouldn't solve it. In the case of your solution (1), you are introducing a mandatory response to every message stanza, and also introducing exciting layer violations. You'd be better off having a "last MAM id" attribute there, actually - still layer violations but much easier to work with on all the servers I've worked on - if you did this, then you'd also be able to drop the mandatory requirement. Ugly, sure, but it might be sufficient. (Fun fact - you could even obviate the need for the '359 insertion at all). Syntactically, this is going to be ugly though - probably a NM bump. (2) and (3) (and your un-numbered proposal) cause both an additional response *and* a further '198 ack back from the client to acknowledge that response, which seems dramatically ugly. Dave.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
