* Marvin W <x...@larma.de> [2020-09-29 12:04]: > I think there is two problems that are somehow merged within this: > > 1. Knowing the last outgoing message's server stanza-id for the purpose > of fetching only newer messages with MAM. > > 2. Knowing all outgoing message's server stanza-id, for undefined purpose. > > While any solution to 2 also solves 1, it may as well be total overkill > if only 1 is to solve.
I gave an example elsewhere in this thread: I think filling holes in the local history can be messy if your DB contains a mix of messages with and without stanza ID. I'd prefer not to implement a solution to (1) just to notice later on that we need a different one that solves both. > I personally would like to not see any solution of servers replying to > every message beyond stream management. And IMO stream management is > definitely a different protocol layer and thus shouldn't be used to > transport server stanza-id used for MAM. BTW, I see how we designed things this way so I do understand how this might break existing API layers, but I don't see how this is the wrong layer per se. Stream management is about acknowledging stanza delivery, and referring to the delivered stanza by ID rather than count seems fine to me. It's done similarly in other protocols. > I personally would like to consider to make the server pick a server > stanza id that the client can know *without* asking the server or > getting it returned. Yes, as I also mentioned elsewhere, that would seem like the most elegant solution to me. I'm just assuming server developers won't necessarily be happy about a standardized stanza ID format. Holger _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
