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 the notifications. 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. -- ralphm