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 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. 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 <[email protected]> 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: [email protected] > > > _______________________________________________ > > > > -- > > Sam Whited > > [email protected] > > _______________________________________________ > > Standards mailing list > > Info: https://mail.jabber.org/mailman/listinfo/standards > > Unsubscribe: [email protected] > > _______________________________________________
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
