Hi, Thank you Matthew for raising that. Regarding that XEP-0060 is stable, I don't think that a new argument is a good idea. I'm more in favor of any of the other options.
If a client may ask for an override, it may be necessary to add a config option to forbid this behaviour. A node owner may have specified a value for a reason, and it would probably be bad UX to make it change transparently because some client thinks that it is better (I realise that this is what is currently happening with the 2 rounds trip, I'm just thinking out loud). Beside that, yeah, let's do some override, as long as nobody is deleting my blog posts by setting `max_item=1` instead of `max` this way. Best, Goffi Le mercredi 28 juin 2023, 13:26:02 CEST Matthew Wild a écrit : > Hi folks, > > Pubsub's <publish-options/> is an important part of the protocol, e.g. > to ensure that private data stays private and isn't accidentally > published to a misconfigured node: > https://xmpp.org/extensions/xep-0060.html#publisher-publish-options > > When the configuration provided by the client in publish-options does > not match the node, XEP-0060 requires the service to reject the > publish with a 'precondition-not-met' error. This lets the client > decide how to proceed. > > My understanding is that most clients today will simply respond to > such an error with a configuration request, to set the node > configuration to what they expect. > > This has a few problems. It's possible that clients might fight over > configuration values (most likely to happen on non-essential options > such as max_items, where maybe one client sets it to 999999 and > another sets it to 'max'). It's also inefficient, especially in the > case where publishes are frequent and two clients disagree over the > correct configuration of the node. > > I'd like to find a way to eliminate the round-trip introduced by the > precondition-not-met error, and allow clients to request that the > server simply overwrites the current configuration options with the > provided values in the case of a mismatch. > > This is theoretically easy to do, because if the server doesn't > support this it will simply return precondition-not-met and the client > can fall back to the traditional behaviour. My question therefore is > more about how we would want the syntax of this change to look. > > For example, we could introduce a new attribute on publish-options, e.g.: > > <publish-options onconflict="overwrite"> > <x xmlns="jabber:x:data">[form here]</x> > </publish-options> > > I suspect some may object to this without a namespace bump (which I'm > sure we all agree is out of the question). > > Or, we can add a new element: > > <publish-options> > <conflict-resolution xmlns="urn:xmpp:pubsub:conflict:0" > behaviour="overwrite" /> > <x xmlns="jabber:x:data">[form here]</x> > </publish-options> > > Or, we could add this as a form field in some way. That could be as a > special-case field, or as an actual node configuration option (which > implies that we could set the default conflict behaviour on a per-node > basis). Note that the latter removes some control from the publishing > client, and potentially changes behaviour for existing clients that > didn't opt in to the new behaviour. > > Before I proceed, does anyone have any strong feelings about any of > this, or shall I close my eyes, pick one at random and PR? :) > > Regards, > Matthew > _______________________________________________ > Standards mailing list -- standards@xmpp.org > Info: Unsubscribe: %(real_name)s-unsubscribe@%(host_name)s > _______________________________________________ > _______________________________________________ Standards mailing list -- standards@xmpp.org Info: Unsubscribe: %(real_name)s-unsubscribe@%(host_name)s _______________________________________________
