Hello Kev, 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...
* Kevin Smith <kevin.sm...@isode.com> [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). Essentially, the interpretation of the XEP boils down to the question whether the @id can be considered as being part of the payload. If you allow that interpretation for a moment, we can explore the other alternative and compare them. > 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) 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'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). 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). Georg
signature.asc
Description: PGP signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
