On Mon, 28 Sep 2020 at 15:44, Holger Weiß <hol...@zedat.fu-berlin.de> wrote:
> * 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: > > I'm not intending to assume, I am intending to consider, to be clear. > - 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. > > This feels like optimizing for a degenerate case. > - 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. > > If we aim to have every outgoing message with a stable id, that's going to mean every message generates a response. That feels undesirable generally. > - 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. > > Yes, this is more complex than it needs to be, in part because we have no guidance here (as Ruslan noted). > To me, it seems way more straightforward to just index the entire local > history by stanza ID. > > OK, counter-thought: To take advantage of this, the client has to change anyway, and we have to negotiate something. Can we get to a point where the MAM id is minted by the client when it sends the stanza, either by agreement that it always uses UUIDs, or something else, in the id of the stanza (and therefore not need a stanza id (and how I hate this nomenclature))? That would then mean the client always knew the MAM id. We can handle clashes by having the server simply reject (with a stanza error) any id that is already in use as a MAM id and this might even be useful for reconnection logic. > > (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? > Which brings us back to pushing this into '198, if we go this route. This allows the client to choose whether it's just the last message in a batch, or every message, that they get a stanza id for, too. > > Holger > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > _______________________________________________ >
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
