Proposed XMPP Extension: Pubsub Extended Subscriptions
The XMPP Extensions Editor has received a proposal for a new XEP. Title: Pubsub Extended Subscriptions Abstract: This specification extends the XMPP PubSub protocol by introducing mechanisms for users to subscribe to an entire node hierarchy or to receive notifications on node metadata updates. URL: https://xmpp.org/extensions/inbox/pubsub-extended- subscription.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP.
URL: https://xmpp.org/extensions/inbox/pubsub-extended- subscription.html
While it works fine and is certainly what I would do in many contexts, I wonder if a negative value is the best we can do for "unlimited". Could we not use a field with no value, or with a descriptive value of "unlimited" (I realize perhaps you want to have this match the data types xep and that's why you restricted to integer)
Le mardi 29 octobre 2024, 14:05:18 heure normale d’Europe centrale Stephen Paul Weber a écrit :
URL: https://xmpp.org/extensions/inbox/pubsub-extended-> >subscription.html
While it works fine and is certainly what I would do in many contexts, I wonder if a negative value is the best we can do for "unlimited". Could we not use a field with no value, or with a descriptive value of "unlimited" (I realize perhaps you want to have this match the data types xep and that's why you restricted to integer)
It's mostly by experience: I've seen many people complaining about `pubsub#max_items` using "max" for no limit, and an integer otherwise, and it's a bit annoying. But I'm open to other solutions. Empty value could do it if no implementation confuse that with no value (which would then be the default "0"). Really I'm open to everything, it's a minor adjustment if the XEP get accepted.
participants (3)
-
Daniel Gultsch -
Goffi -
Stephen Paul Weber