Details

      Description

      Commit log for included patch:

      Add a good chunk of support for XEP-0248: PubSub Collection Nodes.

      • No schema changes. The only change you might need to care about is
        the one for node_default marked 'API-CHANGE'.
      • Notifications can be delivered via collection nodes. These
        notifications are distinguished between item and node types.
      • [API-CHANGE] To accomodate XEP-0060 better, I've allowed owners to
        have subscription 'none'. This required a change in node_default
        when creating the node. If you create your own nodes without using
        node_default's function, you should probably do this, too.
      • Since subscription options aren't available, assume default
        options of depth 'all' and type 'nodes' for collection nodes and
        'items' for leaf nodes. This does violate the XEP, but is still
        pretty useful for most people and without changing schema I'm not
        sure what else to do.
      • Add support for "pubsub#collection" text-multis in node
        configuration form.
      • Support for notifications of: item publish, item retract, node
        configuration, node purge, node creation, node deletion.
      • Fix a bug when notifying about node deletion, where even owners
        wouldn't get a notification.
      • Normalized a lot of the broadcast code to reduce my typing strain.
      • added mod_pubsub:make_stanza/4 to support SHIM headers.
      • added namespace constants to jlib.hrl for SHIM headers.

      MISSING:

      • Subscription options are basically required, but they will require
        a schema change or adding a table.
      • Configuration forms do not distinguish between collection and leaf
        nodes, in violation of the XEP.
      • Subscription depth defaults to all because I can't pass it up from
        get_states/2 in the nodetree module. This also violates the XEP.
      • Localization of configuration form for 'pubsub#collection'

      Additional Notes:

      As alluded to above, this is an almost-completely-backwards-compatible patch. Everything should continue to work using the new support, but new behavior won't be added. The behavior is contingent on a nodetree module which does the right thing, and a change to a node. The node change is straight -forward, so here it is:

      %% Get all the states for the current node and the states for all its
      %% parents.
      get_states(Host, Node) ->
          Parents = nodetree_dag:find_parents(Host, Node),
          QS = qlc:q([State || State <- mnesia:table(pubsub_state),
                               element(2, State#pubsub_state.stateid) == {Host, Node}]),
          QP = qlc:q([State || State <- mnesia:table(pubsub_state),
                              #pubsub_node{nodeid = {PHost, PNode}} <- Parents,
                              element(2, State#pubsub_state.stateid) == {PHost, PNode}]),
          {result, qlc:e(qlc:append(QS, QP))}.
      

      That relies on the nodetree_dag, which I'm including in this mail.

      1. coll-item-publish.patch.gz
        0.6 kB
        Brian Cully
      2. nodetree_dag.erl
        9 kB
        Brian Cully
      3. sub-depth-fix.patch.gz
        0.3 kB
        Brian Cully
      4. xep-0248.patch
        26 kB
        Brian Cully
      5. xep-0248.patch
        26 kB
        Brian Cully
      6. xep-0248.patch.gz
        9 kB
        Brian Cully
      7. xep-0248.patch.gz
        9 kB
        Christophe Romain
      8. xep-0248.patch.gz
        9 kB
        Brian Cully

        Issue Links

          Activity

          Hide
          Christophe Romain
          added a comment -

          all patches included for few weeks, all seems ok. performance impact is negligible when not using dag.
          this is still to be ported to ejabberd-3.0 anyway

          Show
          Christophe Romain
          added a comment - all patches included for few weeks, all seems ok. performance impact is negligible when not using dag. this is still to be ported to ejabberd-3.0 anyway
          Hide
          Christophe Romain
          added a comment -

          i'll close this issue is nobody complains about the feature

          Show
          Christophe Romain
          added a comment - i'll close this issue is nobody complains about the feature
          Hide
          Guillaume Perrot
          added a comment -

          Is this feature available (or planned) in the ODBC version ?
          It seems that collections support needs the "dag_odbc" plugin and threre is no node_dag_odbc.erl/nodetree_dag_odbc files.

          Show
          Guillaume Perrot
          added a comment - Is this feature available (or planned) in the ODBC version ? It seems that collections support needs the "dag_odbc" plugin and threre is no node_dag_odbc.erl/nodetree_dag_odbc files.
          Hide
          Christophe Romain
          added a comment -

          we're waiting for xep-0060 v1.13 to be commited very soon for
          clarification. by now it references xep-0248 which is deferred.
          seems like dag will be dropped from the spec.

          Show
          Christophe Romain
          added a comment - we're waiting for xep-0060 v1.13 to be commited very soon for clarification. by now it references xep-0248 which is deferred. seems like dag will be dropped from the spec.
          Hide
          Christophe Romain
          added a comment -

          i meant, feature not planned in odbc while not sure collection as dag
          remains in the spec

          Show
          Christophe Romain
          added a comment - i meant, feature not planned in odbc while not sure collection as dag remains in the spec

            People

            • Votes:
              2 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Days since last comment:
                4 years, 30 weeks, 5 days ago

                Issue deployment