On Tue, Apr 02, 2019 at 02:15:24PM +0200, Georg Lukas wrote: <snip>
> > > While message reordering doesn't exist in XMPP (at least in theory), > > > [...] all corrections are equal and the latest one wins. > > …which is fine, AFAICS. > > While a little bit tongue-in-cheek, my comment was intended to provoke > further thought. One such situation(*) is when you perform two > corrections of the same message from two different clients, with the > corrections arriving at the recipient in arbitrary order. The 'wrong' > approach spans a tree of message corrections leading to the original > message as its root. A recipient will end up showing all leaf messages > (because it won't be able to merge different sub-trees) as long as order > is maintained over each sub-tree. With the 'right' approach, all > corrections are leafs of the original, leaving the most > delayed correction as the winner(**). Are you arguing against your own suggested "chained" approach here? Seems to me this is a problem that would only arise when using the chained approach because then two correcting messages referring to the same ancestor "id" require you to turn your linked list into a tree. When implementing the current version of the spec (made more explicit with Kev's clarification) this problem won't arise because the list of correcting messages is ordered based on reception date, not linked via their "id" attributes. <snip> - JC _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
