"Simplify, simplify, simplify." --Thoreau
The XMPP publish-subscribe extension is traditionally considered a bit intimidating. Yes, it's the largest XEP we've published. There are lots of options and potential error flows, but the basic concept is not all that difficult to grok: you've got a node/channel and you can publish items to it; other people can subscribe to the node and be notified when you publish items. A handy thing for pushing out RSS/Atom feeds, extended presence events like geolocation changes, and so on. It enables a whole world of interaction between people and applications. Yay!
But there's that whole complexity thing happening here. So we've defined a simplified profile of pubsub called personal eventing (a.k.a. PEP). This makes it much simpler to subscribe to nodes if you share presence with the publisher or the service. But it doesn't greatly simplify the publishing process, and that has people concerned.
There's a fairly close analogy between multi-user chat and pubsub (in fact MUC is basically a kind of pubsub, no?). Peter Millard and I borrowed from MUC when we came up with the idea of pubsub affiliations/roles (pubsub node owner, publisher, and subscriber are like MUC room owner, admin, and visitor). But we didn't borrow from MUC by defining node types on the analogy of room type.
We keep getting back to the idea that pubsub is hard. Too hard. Part of the challenge we're facing on the publish side is all those node configuration options. Gosh, how do you choose what the node is supposed to look like? Wouldn't it be easier if there were a short list of node types to choose from? (I posted about this two weeks ago but didn't get any response on the standards@xmpp.org list so I figured I'd explore it further via blog, especially since it came up again at the devcon last week.)
So here are some possible node types:
Well those all pretty much map to the access models, no? So far so good.
Then we can add another dimension: whether items are persisted or not (similar perhaps to whether occupant JIDs are exposed in a MUC room). We'll call this storage vs. eventing. Thus you could have a public storage node, a private eventing node, etc.
Well mostly I'm just trying this on for size right now. I don't know if these distinctions help or hurt. They do seem fairly intuitive. Maybe publishing clients can use these ideas to show node creation / configuration options to end users. Feel free to comment if you have feedback. :)