| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
Extra-extra obvious that no interaction with this should lead to
persisted changes
|
|
|
|
|
| |
I'm not sure what went wrong here, copy-paste mistake?
Doesn't matter as long as nobody can create nodes on this service.
|
|
|
|
|
| |
Previously this would end up passing the "max" directly to the
underlying storage.
|
|\ |
|
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| |
| | |
Using a dedicated service should give identical behavior, except for a
possible timing difference in the user existence lookup.
|
| | |
|
| | |
|
| |
| |
| |
| | |
Ensures configuration is refreshed, releases some memory.
|
| |
| |
| |
| |
| | |
It was previously set to the hostname, not the users bare JID which
would be correct.
|
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| |
| |
| | |
Fixes #1643
API change: The argument to archive_itemstore() changes type to integer
|
|\| |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
|\| |
|
| |
| |
| |
| |
| | |
Noticed while discussing feature discovery in Gajim
Thanks lovetox
|
|\| |
|
| | |
|
|\| |
|
| |
| |
| |
| | |
Take two on 045209b41b3a
|
| |
| |
| |
| |
| |
| |
| | |
Once upon a time get_pep_service() would get called with random bare
JIDs and remote hostnames, which is why it was logged this way. This
seems to have been fixed, so it's not as useful anymore. It's still
useful to know when it creates a new service object.
|
| |
| |
| |
| | |
Having the node logged is more useful and less problematic for privacy
|
|\ \
| |/
|/| |
|
| |\ |
|
| |\ \ |
|
| | | |
| | | |
| | | |
| | | | |
mod_pubsub got this in f2d35eee69c9
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
This eases comparing and contrasting these two modules.
|
| | | | |
|
| |_|/
|/| |
| | |
| | |
| | |
| | | |
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.
|
|/ |
|
| |
|
|
|
|
|
| |
Replaces automatic node creation on subscription, since this casues
problems when trying to keep nodes private or other specific settings.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
across reloads
|
| |
|
|
|
|
| |
This is added in pubsub.lib
|
|
|
|
| |
access-* is added in pubsub.lib based on node defaults
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
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.
|