17 Oct
2024
17 Oct
'24
1:09 a.m.
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.
29 Oct
29 Oct
7:05 a.m.
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)
8:18 a.m.
Le mardi 29 octobre 2024, 14:05:18 heure normale d’Europe centrale Stephen
Paul Weber a écrit :
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.
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)
19
days inactive
31
days old
2 comments
3 participants
participants (3)
-
Daniel Gultsch -
Goffi -
Stephen Paul Weber