Hi to all, 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). Further problems solved by the one-bookmark-per-item approach: * We get the notifications that have single bookmark granularity and we do not have to diff the entire bookmark lists against our current bookmark list to notify the application of bookmark changes. * We have no trouble preserving non-standard elements in bookmarks we do not touch. * The change allows O(1) book-keeping for clients tracking the current bookmark list, instead of O(n) book-keeping necessary if all bookmarks have to be retrieved at once. This is especially beneficial from a bandwidth perspective. * no more questions on how to treat duplicate bookmarks for the same jid. > For what it's worth, I did get that from the text. My point was that it'd > be helpful to have the pubsub details in an example. I agree, that would indeed be helpful (and coherent with other XEPs, where there are usually examples of full stanzas for the use-cases). While first skimming the document I actually thought the jid attribute of the bookmarks was missing. Kind regards, Sebastian
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
