Allows e.g. restricting your vcard4 to only family or similar.
Notes: This does not include roster groups in the configuration form,
so the client will have to get them from the actual roster.
Many of these fall into a few categories:
- util.cache size, must be >= 1
- byte or item counts that logically can't be negative
- port numbers that should be in 1..0xffff
This gives the broadcaster access to the node configuration, which is now
important for itemreply. It probably also fixes a bug with the notify_*
node config options?
This matches ejabberd's behaviour, using the 'pubsub#itemreply' config option.
Although the current definition of this option in the specification is not
as clear as it could be, I think matching what existing deployments do is the
best option to resolve the ambiguity and reduce fragmentation.
We should update the spec to be clearer about how to use and interpret this
option.
The 'expose_publisher' option for mod_pubsub is now an override (always expose
or never expose). If unset, it will use the per-node config (which defaults to
not exposing).
Thanks to Link Mauve, edhelas and goffi for sparking this feature.
Data is already wiped from storage, but this ensures everything is
properly unsubscribed, possibly with notifications etc.
Clears recipient cache as well, since it is no longer relevant.
Originally added in 202b9951b037 but util.pubsub gained a better method
in 6c2c2fc4b8dd since then, which mod_pep uses since 9194431b6447 which
should have deleted this.
All these :create calls would have failed with a 'conflict' error, since
the nodes had already been created. This was never noticed because of
missing error handling.
Also note that this code did not restore node configuration.
Clients would generally be using the "max" symbol instead of discovering
this, but this also gets us validation and earlier rejection of out of
bounds values.
Default left as 'never' in mod_pubsub to preserve the previous behavior.
Unclear if this is desirable, but can always be changed later.
In mod_pep this allows turning off the automatic resending of most
recent item.
This behavior came from some confusion over the meaning of
persist_items. The correct behavior is that items are only stored when
it is set to true. When set to false, the service becomes a "pure"
publish-subscribe service, where items are forgotten immediately after
broadcasting.
Adding in all presence based subscriptions in the broadcaster caused
resend_last_item() to unintentionally send out more notifications than
it should have.
Subscriptions were updated for each incoming presence stanza from
contacts. Each subscription change triggered a configuration save, which
would filter out the presence based subscriptions and usually end up
replacing the existing data with identical data. With many subscribed
nodes this adds up to a fair bit of IO bound work that is avoided by
keeping them separate.
It stored the caps hash as a string in the recipients table while
waiting for a disco#info response, then replaces it with the set of
nodes that had +notify.
This mixing of types is bad, so here it gets removed.
This can be improved once an IQ tracking API (#714) is added.
This moves some XEP-0060 awkwardness out of util.pubsub and into mod_pubsub
A retraction is broadcast in an <items> container, whereas most other
kinds of broadcasts are in a container with a name matching the 'kind'
attribute.
