[Standards] Bookmarks 2 extensibility

Florian Schmaus flo at geekplace.eu
Tue Nov 26 18:31:46 UTC 2019


On 24.11.19 10:11, Emmanuel Gil Peyrot wrote:
> Hello standards@,
> 
> One of the issues with 0048 bookmarks was that any extension to a
> bookmark was possibly removed by another client which didn’t know what
> to do with it.
> 
> I’d like to achieve something better for bookmarks 2, so that clients
> can attach private or shared extensions and compatible clients can read
> them, while non-compatible clients would ignore them.
> 
> 
> I’m suggesting adding a <{bookmarks:0}extensions/> element inside the
> <{bookmarks:0}conference/>, where clients and servers alike MUST
> preserve the content if they don’t understand it.

+1.

I especially like the proposed <extensions/> element as clear defined
extension point and had probably designed it the same way.

I ponder about possible server-generated metadata in the MUC bookmarks
as future protocol extension. Something like the last time you joined
this MUC, or, if you are currently joined this MUC with a different
client. And the <extension/> element makes it possible to distinguish
between client-side extension of the bookmark, which need to be replayed
in full on bookmark modification, and server-side extensions.

- Florian

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


More information about the Standards mailing list