[IOT] PubSub Collection Nodes. Was: Re: Feedback on pubsub for IoT
ralphm at ik.nu
Tue May 19 10:14:37 UTC 2015
On 2015-05-18 09:49, Cramer, E.R. (Eelco) wrote:
> What worries me is that pubsub collection nodes
> (http://xmpp.org/extensions/xep-0248.html) is a deferred XEP. Do you
> know if there are any XMPP servers that implement this? It would be
> worth checking why this XEP was deferred…
The reason is that this XEP needs work. As-is, it is way too complicated
and if nobody actually has an interest (= doing something) to move the
XEP forward, it will stay deferred.
I currently have no motivation to work on collections in general, even
though I am listed as one of the authors of the current document. The
complexity is one reason.
The other is that I believe that in practice, having a generic
publish-subscribe service, where you have to explicitly create nodes and
set up collections, while your actual business logic is elsewhere, is
*very* cumbersome. From experience I know that such state
synchronisation is a huge pain.
The alternative I favour is a service that provides an XMPP
Publish-Subscribe /interface/ on top of the business logic. This way,
nodes just exist as side effect of the business logic, depending on
whether or not someone is subscribed to it. This is also sometimes
referred to as code-as-node.
If devices represent themselves as entities with a pubsub service that
exposes nodes, this might work well. I do realise that currently we have
no standardised way for a device to connect to a server as a bare JID
(as opposed to a regular client connection that connects as a resource
thereof), but this would be my dream scenario. YMMV.
The only thing I *do* like is the concept of a root node, which is
basically the firehose for the entire service. A combination with
content-based subscriptions might also be interesting. Possibly also
non-root nodes that publish items from other nodes based on some
criteria, which reflect the original node the item was published to in
What I am not sure about any more, is if the choice of having the node
identifier on the notification be the original node, while the
collection node is referred to in SHIM headers. Maybe it should be the
other way around.
More information about the IOT