On Tue, Apr 02, 2019 at 12:06:20PM +0200, Georg Lukas wrote: <snip>
> While message reordering doesn't exist in XMPP (at least in theory), the > "blockchain" of corrections provides a cleanly ordered relation over all > corresponding corrections, whereas with the 'right' way, all corrections > are equal and the latest one wins. > > However, if you are receiving partial history from MAM or a MUC, it is > well possible that the original message was either lost (because it's > older than the retention interval), or is going to be loaded later as > part of a history scroll back. > > In this case, the 'right' way to interpret the first correction you > receive is "inject a new message placeholder into the history, with > unknown timestamp and no payload, then perform a correction on that". > With the 'wrong' way, the first correction just naturally becomes the > original message if it corrects an unknown @id. I think with MAM catchup, the current reading of the spec (i.e. non-chained) actually makes things easier. With the chained approach, if you get only part of the chain, you'll need to memorize somewhere that you're still waiting for an older message with a particular id (and then when doing another MAM query you need to check whether you got a message with that id). With the non-chained approach, you can simply make a placeholder message (like you suggested) and annotate corrections onto it (ordered by time received). No need to store not-yet-received ids anywhere. > I'm not sure which way is superior for handling an after-the-fact > appearance of the original message. I'd also like to hear opinions from > server archive developers. > > I did that. It would be great if you didn’t -1 the clarification :p > > It is well possible that my interpretation of the XEP ambiguity was > not quite correct. However, it is shared by other widely deployed(?) > implementations, and removing the ambiguity would be a breaking change > to all those (and yes, I'm obviously biased here because of my own one). As Kev already mentioned, there are other clients that implemented it according to the way the XEP was intended, including mine. What you're proposing would in any case require a namespace version bump right? Given that, I think it's fair to merge Kev's clarification of the intent of the current version regardless of whether the chained approach gets accepted or not. - JC _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
