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

Guus der Kinderen guus.der.kinderen at gmail.com
Sun Mar 18 20:30:37 UTC 2018


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.


> > I appreciate
> > how it fits in nicely with the way how pubsub is designed - but in
> > practice, I suspect that one would easily work with entire sets of
> > bookmarks anyways. By not splitting up the bookmarks, we wouldn't need a
> > new namespace, and we can re-use the existing 0048/0049 data structure.
> > That will improve interoperability, and make adoption easier.
>
> We’ve been advocating this (split into items) move for quite a while and
> we’re
> happy to see that it’s happening now.
>
> > Unrelated: I'd like the XEP to have a "complete" example of a bookmark,
> one
> > that includes the room JID. Although the text is clear, having an example
> > like that will be a useful illustration.
>
> The text doesn’t seem to be that clear then; the idea is that the JID is in
> the pubsub item ID (§ 4.1) -- which also has the nice sideeffect of
> resolving
> the ambiguities which arise when multiple bookmarks for the same room with
> different nicknames exist.
>
>
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.


> kind regards,
> Jonas
>
>    [1]: https://github.com/horazont/aioxmpp/blob/devel/aioxmpp/bookmarks/
> service.py#L416
>
> >
> > On 18 March 2018 at 16:25, Sam Whited <sam at samwhited.com> wrote:
> > > Looks great, thanks Dave and JC!
> > >
> > > The only feedback I'd like to give is that the password field should be
> > > removed. If use of the password field is not recommended, why have it?
> It
> > > seems perfectly fine to say that you can't autojoin password protected
> > > MUCs
> > > without a prompt or that individual clients must store the password (so
> > > you'd have to log in once on each client the first time it fetches the
> > > bookmarks and joins the room).
> > >
> > > —Sam
> > >
> > > On Sun, Mar 18, 2018, at 08:34, Jonas Wielicki wrote:
> > > > The XMPP Extensions Editor has received a proposal for a new XEP.
> > > >
> > > > Title: Bookmarks 2 (This Time it's Serious)
> > > > Abstract:
> > > > This specification defines a syntax and storage profile for keeping a
> > > > list of chatroom bookmarks on the server.
> > > >
> > > > URL: https://xmpp.org/extensions/inbox/bookmarks2.html
> > > >
> > > > The Council will decide in the next two weeks whether to accept this
> > > > proposal as an official XEP.
> > > > _______________________________________________
> > > > Standards mailing list
> > > > Info: https://mail.jabber.org/mailman/listinfo/standards
> > > > Unsubscribe: Standards-unsubscribe at xmpp.org
> > > > _______________________________________________
> > >
> > > --
> > > Sam Whited
> > > sam at samwhited.com
> > > _______________________________________________
> > > Standards mailing list
> > > Info: https://mail.jabber.org/mailman/listinfo/standards
> > > Unsubscribe: Standards-unsubscribe at xmpp.org
> > > _______________________________________________
>
>
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20180318/15602e16/attachment-0001.html>


More information about the Standards mailing list