* Dave Cridland <d...@cridland.net> [2020-09-28 09:51]: > 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.
You seem to be comparing the additional traffic generated by MAM results containing outgoing messages to the traffic generated by archiving ACKs, and assume the latter to be worse. My point wasn't about traffic optimization though. A de-dup-based solution just feels like an ugly hack to me, which means I see at least the following problems: - Your conclusion regarding the traffic comparison relies on the assumption that inbound and outbound traffic are somewhat balanced. This assumption probably holds for typical (IM) use cases, but it's obviously not true under all circumstances. If sessions may end with significant amounts of outgoing messages, it may well be preferable to spread stanza ID traffic over the session, rather than having to start the next one with a burst of MAM traffic required for de-dup. Whereas ACK traffic just adds a small percentage of traffic under all workloads in a stable manner. - MAM clients might sync just recent messages to local storage, not the entire history. So local storage might end up with holes. Which the client might attempt to fill, if, for example, the user scrolls up to those missing parts of the history. At that point, I think it becomes increasingly messy to deal with a mix of local messages that do include a stanza ID and those that don't. - Most importantly, I think our current solutions just feel highly weirdo to (new) XMPP client developers, and add to the impression that XMPP is hard to approach. I've been asked several times by different client developers about how to sync outgoing messages from MAM. Right now my response looks like "use the last known stanza ID, then de-dup outgoing messages returned from MAM by looking up some other ID in your local DB, and then update the DB row with the stanza ID". And then I hope they still won't run away screaming. To me, it seems way more straightforward to just index the entire local history by stanza ID. > (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. The server might choose not to request a 0198 ACK for those stanzas; but yes, this does seem ugly. Maybe reason enough to make this a non-stanza stream element? Holger _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
