On 2 Apr 2019, at 11:06, Georg Lukas <[email protected]> wrote: > thank you for picking this up again, and I'm sorry for the -1. I wrote > in the Meeting that it's not impossible to convince me to change my > mind, but you have to provide very strong arguments…
I don’t really think what you’re looking for here is a clarification of the intent of the XEP, but a change of behaviour. There are plenty of pointers in the XEP at the moment to the intention - saying not to change the nature of the stanza (which naturally includes its identity), correcting a single message multiple times (not correcting a chain of messages), only replacing the payloads, etc. - my PR clarified this, although I don’t pretend that my PR is perfect, or removes all other opportunities for clarity in 308. > * Kevin Smith <[email protected]> [2019-04-02 10:52]: >> It’s the original message @id - if you follow the rules in the XEP >> then the other way around wouldn’t work. > > I'm not convinced that it really wouldn't work (and my lack of > conviction is backed by yaxim doing it the "wrong" way and not failing). Of course it could be made to work, but only by munging bits of the XEP as-is, particularly: > Essentially, the interpretation of the XEP boils down to the question > whether the @id can be considered as being part of the payload. Which is not the usual interpretation, which is that it’s the content data (see XEP-0060, for example, for this use of the term). I accept that what I should have written was not the colloquial ‘payload’ but its meaning ‘child elements’ - this would be a purely editorial change, so I can submit a PR for this straightforwardly. > If you > allow that interpretation for a moment, we can explore the other > alternative and compare them. Yes, if you ignore this bit of the intent, everything else can be bashed into working (although with issues, as below). >> If you do this the ‘right’ way [...]: >> >> <m id=1><b>fixed</b></m> >> <m id=2><b>typo 2</b><r id=1/></m> >> <m id=3><b>fixed</b><r id=1/></m> >> >> Where, again, 2 and 3 can be forgotten, or simply ignored. > > Regarding client-side storage, you can only delete the correction > messages if you do not intend to provide the full message editing > history to the user. If you plan to provide such history, it obviously > doesn't make sense to rewrite the original message (and thus remove its > content from the history). Instead, you probably need to copy the > original and intermediate corrections into a dedicated storage table, > where I can see that a stable reference identifier (id=1) over all > corrections makes some sense. > > The 'wrong' way would include also rewriting the @id of the stored > message with the @id of the last correction you received. The example > would thus become: > >> <m id=3><b>fixed</b></m> >> <m id=2><b>typo 2</b><r id=1/></m> >> <m id=3><b>fixed</b><r id=2/></m> > (and you will drop the correction messages) As further evidence that this isn’t a good idea, it’ll break anything else using the id - e.g. message receipts. > 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. …which is fine, AFAICS. > 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. That would then mean you’d end up with out-of-order messages, because of the corrections, so I think in both cases you need to wait for the first message (or elide the corrections) to have a sensible stream. > 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. With one of my other hats on, if we’re going to have a server archive that understands corrections (and other references, as we discussed at the Summit), which we’re going to need, it’s going to be much more straightforward to have everything anchoring off a single message, rather than needing to follow a chain. >> 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). There are also implementations with the intended interpretation, FWIW. > > Together with the nice and clean "blockchain" ordering of the 'wrong' > interpretation, however, I remain unconvinced that your PR is the right > direction of removing the ambiguity and want to hear more voices (and/or > better arguments). I can certainly attest that it was the intention when writing the XEP, and although it’s possible to squint carefully at the words to get a different meaning, as above, we need to decide whether what we’re asking for is to clarify it (which my PR does), or to change the intended behaviour. I, naturally, prefer the clarification route /K _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
