[Standards] Bookmarks 2 extensibility
dave at cridland.net
Mon Dec 9 17:49:58 UTC 2019
On Wed, 4 Dec 2019 at 21:07, Florian Schmaus <flo at geekplace.eu> wrote:
> On 26.11.19 20:48, Dave Cridland wrote:
> > On Tue, 26 Nov 2019 at 18:46, Florian Schmaus <flo at geekplace.eu
> > <mailto:flo at geekplace.eu>> wrote:
> > On 25.11.19 14:16, Dave Cridland wrote:
> > > As a general rule, I think clients need to try and
> > preserve unknown XML
> > > nodes in data they manipulate. This goes for PEP data, roster
> > data, and
> > > all sorts.
> > I don't share that sentiment. Clearly XMPP entities need to simply
> > ignore unknown extension elements if they are just consuming them.
> > in cases where entities are modifying elements, like roster data,
> > demanding that they have to replay also all unknown extension
> > is, among other things, dangerous: One rotten apple could destroy the
> > whole batch. That is, one misbehaving client could ruin everything.
> > is why I hope that we will never put extension elements in roster
> > <item/>s that the client needs to replay .
> > In such cases I instead favour the approach Emmanuel suggests:
> > define extension points and explicitly state the requirement to
> > handle/preserve unknown XML in the specification.
> > OK - I disagree, but I also think this is an acceptable compromise.
> > Should server-generated metadata also have a container element, so that
> > clients know it can be ignored and must not be replayed?
> > Should these elements be generic elements, common across all cases, or
> > do we make them individually each time?
> Good questions. I do not have a strong opinion regarding the answer.
> Mostly because I can not come up with an example or reason that
> demonstrates that there is value in having a generic element or a
> container element for server-generated metadata. That does not mean that
> such a thing does not exists though.
I think the summary, then, is that:
* Some elements are part of the core specification and must always be
* Some elements are private client extensions and must be preserved
unchanged by other clients.
* Some elements are server-driven extensions and should not be preserved
explicitly by the client, and may be ignored.
My gut feeling is that the latter two ought to sit in a container element,
to provide the most flexible solution.
If that sounds right, I'll prepare a PR.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards