[Standards] Proposed XMPP Extension: Bookmarks 2 (This Time it's Serious)

Sebastian Riese s.riese at zombofant.net
Sun Mar 18 21:59:08 UTC 2018


Hi to all,

On 18.03.2018 21:30, Guus der Kinderen wrote:
> On 18 March 2018 at 18:56, Jonas Wielicki <jonas at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 866 bytes
Desc: OpenPGP digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20180318/c39cb76e/attachment.sig>


More information about the Standards mailing list