powered by Jive Software

PubSub service implementation not fully according XEP-0060

Hello all,

i noticed, that current implementation of the PubSub service is not behaving fully according XEP-0060.
To be more specific, what’s not working is following:
Notifications are not sent to subscribers upon node configuration change and upon node deletion

  1. “Node configuration change” message was not sent to subscribers(“nodes”) of any parent nodes even when the depth was proper. Only if subscription was made directly to node which configuration was changed
  2. “Node configuration change” message was not sent to subscribers (“nodes”) of any parent nodes even when the depth was proper, because the node was deleted 1st from collection and therefore not found as descendant node later when the notification messages were sent.

It was tested with OF v4.5.0 and v4.5.1

I already created a pull request on github: https://github.com/igniterealtime/Openfire/pull/1579
But i guess the right way is to first discuss it here…

Greetings, Sorry that your PR has yet to be reviewed. We are always tight on volunteers and even tighter on those that understand pubsub!

Hi Daryl,

of course i understand the circumstances. That’s why i decided to try to implement the fix myself…hopefully i did it right.

This looks like a good improvement. Did you verify if this bubbles up a chain of parent/child relationships? Also, when a node is deleted, does this bubble down all child nodes (I’m assuming that those are considered ‘deleted’ too?)

I did verify the “bubbling up”, because this is the typical scenario, when you subscribe to one of the parents, without a need to subscribe to every single child.
“Bubbling down” works a little different. When you delete a node(collection) which still has some children, those are not deleted, instead their parent changes to the parent of the currently deleted node. By other words, their configuration attribute(pubsub#collection) changes.

1 Like

I am curious to which sections or sentences you are referring in XEP-0060. I couldn’t find any descriptions of the “bubbling” behavior of configuration change or node deletion events.

I just continued to use the “bubbling” word started by @guus. Basically It refers to

 <field var='pubsub#notify_config'
         label='Whether to notify subscribers when the node configuration changes'/>
  <field var='pubsub#notify_delete'
         label='Whether to notify subscribers when the node is deleted'/>


But where does it say, that you if you are subscribed to a leaf node, that you are also implicitly subscribed to its parent node?

I have found this in XEP-0248:


This subscription option enables the subscriber to specify how far to traverse the node graph when determining whether a notification will be sent. It may be any integer value, 0 or greater, or the value “all” which means that any node within the collection will generate a notification.

The default value of this subscription option SHOULD be “1”.

I think pubsub#subscription_depth must be set to “all” in order for your fix to be correct. And/or should respect the integer value of that property. Is that the case?

But where does it say, that you if you are subscribed to a leaf node, that you are also implicitly subscribed to its parent node?

I’m not aware about anyone saying it.
pubsub#subscription_depth applies for descendant nodes

<field var='pubsub#subscription_depth'
    <option label='Receive notification from direct child nodes only'>
    <option label='Receive notification from all descendent nodes'>

Ok, maybe I misunderstood.

Your PR looks for me like this:
You modify a child node’s configuration, and now send an notification to the subscribers of its parent node?

I still don’t find the description for this behavior.

My understanding based on what’s written in XEP-0060 is following: Success With Notifications

If the “pubsub#notify_config” option is set to true, the service MUST notify subscribers of the configuration change. (A service SHOULD support this option for leaf nodes and MUST support it for collection nodes as described in XEP-0248.) If the node configuration is set to notification-only, the notification MUST consist of an empty element whose ‘node’ attribute is set to the NodeID of the node; if the node configuration is set to full payloads, the element MUST in addition contain the node configuration as represented via the Data Forms protocol.

Subscriber of the node, which configuration is being changed, is any Ancestor with proper depth and proper pubsub#subscription_type