On 18 March 2018 at 21:59, Sebastian Riese <s.ri...@zombofant.net> wrote: > On 18.03.2018 21:30, Guus der Kinderen wrote: >> On 18 March 2018 at 18:56, Jonas Wielicki <jo...@wielicki.name> wrote: >> >>> On Sonntag, 18. März 2018 18:48:49 CET Guus der Kinderen wrote: >>>> Having implemented 0048 via 0223 earlier this week, I can only applaud an >>>> effort of making the documentation easier to digest. Thanks for this! >>>> >>>> I am, however not sold on the idea of having a bookmark-per-item: what >>>> problem is that solving, or what benefit does this give us? >>> >>> Two or more clients updating different bookmarks at the same time (or >>> maybe at >>> different times, but one had a network outage inbetween and can only >>> actually >>> perform the update at a later time). Currently, it requires a nasty loop >>> [1] >>> until convergence to make that work. >>> >>> >> I didn't think of that. It does, however, seem like a very unlikely problem >> to have occur. On top of that, I don't think that the new XEP fixes the >> address when both clients are updating the same bookmark. > > While the problem may occur seldom in practice, it should be fixed if it > can be fixed. (And with flaky network connections or clients that do not > check the bookmark list before making changes it may not be that seldom). > > As for the "the same bookmark" problem: there is no solution in that > case other than making atomic changes (since we have no way to decide > which change is "right"), and making atomic changes to a single bookmark > *is* possible with the PEP method: We simple need to publish our new > item, and if there's a concurrent change by another client, our change > will be overwritten (or that change will be overwritten). But that's not > a problem (as long as the state is always consistent and we do not lose > items unrelated to the change).
Agreed. We have a number of operations like this in XMPP. In fact, just about all of them. Roster modifications for example. We get away with it because as you say, conflicts are seldom in practice, and the effects are just overwriting a single item with whichever came last. Which if you are thinking about conflict resolution, isn't a terrible strategy in this case, especially when for most situations the change was triggered by a human. > Further problems solved by the one-bookmark-per-item approach: A good list. I was previously on the fence about per-item bookmarks (that is, I didn't much care about which solution was adopted). However after you list all these points out, I'm pretty convinced that per-item is indeed the way to go. Regards, Matthew _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
