On 29 Apr 2015, at 16:44, Peter Waher <Peter.Waher@clayster.com> wrote:

The first idea is a slight modification of the approach: Instead of having the dealer subscribe to all nodes. This might require a lot of administrative communication, and also a lot of monitoring/supervision for make sure it recovers from different error states. An alternative is to make a component connection (XEP-0114) and publish the dealer as a pubsub server component on the xmpp server, replacing perhaps the “normal” pubsub server. In this way, the dealer would not need to maintain all subscriptions, instead, it would be the owner of the nodes itself. Perhaps the added effort here, is comparable or less than the effort needed to subscribe to all events from a pubsub server, that as you say, anyway might be lacking in some regards. The dealer could still use the iot-event subscription architecture, and so, there would not be a need to implement that part, since it doesn’t provide subscribers to request tailored sets of data.

The second idea, is a continuation of the above, but providing a “normal” pubsub subscription interface: Today, the pubsub pattern has a great weakness: It’s not possible to adapt contents based on rights for individual subscriptions. You need to publish different sets of content on different nodes, which quickly grows to infinity if you allow fine-grained control, as is the case for IoT. This not only becomes complicated, it also quickly removes any gains provided by pubsub, as the basic idea is to reduce the number of packets required for the publisher, to efficiently publish information to a larger set of subscribers. So, while one is creating a component for a new type of pubsub service above, you might build in a connection to a provisioning server (XEP-0324), or build in the same functionality in the same component, and use <canRead> to check what type of information is allowed for different subscribers implicitly, removing the need for a tailored subscription request, as well as a tailored publication, still tailoring output to each subscriber. That would lift the burden from the device, and provide a completely new type of service: Context sensitive, or individually tailored, publish/subscribe.

I have thought about implementing the second idea above, myself. I think such a component might have a very important role for the publish/subscribe pattern in XMPP, and solves many of the security issues in other pubsub solutions. Would you be interested in investigating this further?

A third idea, based on the second idea above is the following: Something that is missing from the XMPP pubsub model, but is available in MQTT, is multi-layered publish/subscribe. While implementing a new context-sensitive pubsub service, this might be something to add. In MQTT you can listen to a “parent node”, or wildcards, and receive events from all its (grand*)child nodes for example. Example: Consider you publish a temperature on node building/floor/apartment/room/temp1. How would you do to listen to all sensors in that room? Or all sensors in that apartment, floor or building? Or all temperature sensors in that building (leaving out other kinds of sensors)? Using a wildcard character (*) you could do this by subscribing to “building/floor/apartment/room/*”, “building/floor/apartment/*”, “building/floor/*”, “building/*” and “building/*/*/*/temp*” respectively in one go. That would provide a great way to subscribe to larger sets of contents, without having to maintain huge amounts of smaller individual subscriptions.