On Sonntag, 24. November 2019 10:11:06 CET 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.
>
> Some examples I’ve seen in the wild include Gajim serialising the room’s
> state (whether it’s minimised in the roster), some clients storing tags
> or a hierarchical structure for easier searching. All of those are
> usecases that hadn’t been thought about for the first bookmarks version,
> and that’s fine as long as we can extend it.
>
> 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. Any downside to this
> approach?
The only obvious downside is that some entities may discard unknown data early
in their stack for whatever reasons; I think you can actually get away with
that in all cases (possibly except XHTML-IM) so far. Those entities might then
have to change a considerable part of their deserialisation stack.
However, I’m not sure if there even is a viable alternative. It would be
possible to use additional PEP nodes, but then the entities managing them
would have to take care to update them when the original node updates and
things may easily get out of sync. So keeping the data in the same node makes
sense.
The only thing I wonder is: Why an extra sub-element? This reminds me of the
`X-` prefix which has since been deprecated. We *do* have namespacing in XML,
let’s make use of that. Simply state that all unknown child elements of the
<{bookmarks:0}conference/> element must be preserved; no need to stuff it away
in an extra element.
kind regards,
Jonas
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
