[PubSub] Collection Nodes (XEP-0248)

Brian Cully bcully at gmail.com
Tue Aug 24 17:04:44 CDT 2010

On 24-Aug-2010, at 17:42, Dave Cridland wrote:

> On Tue Aug 24 22:21:06 2010, Brian Cully wrote:
>> > - Retrieve subscriptions - should we return all subscriptions affecting the node (ie, include any which would cause a notification), or just the "local" subscriptions.
>> 	I think this should only return subscriptions on the collection itself, since it's the least ambiguous and other mechanisms exist for finding subscriptions.
> Okay, but this means it's a complex task to find "who will receive notifications from this node".

	Yeah, that's true. However, the pubsub#owner version of "subscription" lacks a "node" attribute. If one were added it would be fairly trivial to return all associated subscriptions. I'm not entirely sure it's worth it. Do you have a use case?

>> 	There are pros and cons to both approaches. I think, but maybe I'm over thinking, that notifications on a closed node can be routed through an open one has configuration benefits. For instance, a service can control access to a set of nodes via a collection choke-point. Imagine nodes A, B, and C connected to a collection node Z. A, B, and C are closed, Z is open. Clients cannot directly subscribe to A, B, or C, but can to Z. At some point the service determines that node C should be completely private and simply dissociates it from Z. If the service had to deal with subscriptions to C it leads to more complicated logic on the owner's end. Personally, I think if you want to make sure a node is closed you don't allow it to associate to an open node (but this is at the owner, not service, level). It seems straightforward and less likely to induce headdesking.
> Well, the use-case I have is PEP. In PEP, the auto-subscription is on the root collection. Your method mandates that all PEP nodes are either not in the root collection (directly or indirectly), or effectively follow the same access model, which seems less than optimal.
> Otherwise, it's possible to have my Tune only shown to people I think won't laugh at my quaintly outdated love of 80's electronica.

	I can see your problem. I hadn't been thinking of PEP as a use-case for collections, but it does make sense. I think there's a general issue here with access models, but I haven't entirely wrapped my head around it yet. I'll stick this in my file of things to try to solve.

>> >> 	I'm on the fence about SHIM headers. I think we need a new one because of the limitations of the schema, or perhaps we should omit the "Collection" header when SubIDs are extant because it's redundant in that case.
>> > I'm not sure it actually is. Are SubID's mandated to be unique across a service?
>> 	Ah, true. IIRC, they only need to be unique to a node. Argh. I hate this problem.
> Remember that it's possible to add requirements to XEP-0248 supporting services.

	I'm loathe to change SubID semantics for collection nodes. Making the SubID for one node depend on its associated nodes seems needlessly complex for what's almost a non-problem. The SHIM stuff is informational, not necessarily operational, IMHO.

> Right, but we could just replace the SHIM with some purpose-specific metadata elements.

	Where would you put it? I don't think we should add another attribute to the <item/> element, nor should we mess with the payload, which leaves adding it as a peer to the <item/>. It smells clunky since we've already got SHIM to deal with there, but it might be the best solution.

> Erm, I've implemented a "full DAG" case, with a (non-mandatory) root collection, and I don't recurse when delivering item notifications. That would suck, performance-wise.

	I'm not sure how you're doing that without traversing the DAG. My DAGs don't get very deep, so the performance problem is negligible for me. Gather up a list of connected nodes and then gather the items on them. I do basically the same thing in reverse when I get a publish event. I'm just walking the tree up instead of down.

> OTOH, I see your point regarding fetching items.
> I'll kick some mental tyres and see what can be done.
> The thing that does spring to mind is that the more we make collections look like aggregate nodes, the more we'll want them to be aggregate nodes. This suggests that it might be interesting, for example, to make them show subscriptions in an aggregate manner, to have a default of items for subscriptions, to have a "forwarding" node for publish events, etc.

	This does have a certain amount of mental clarity, which I like, but I worry it's getting too far away from the DAG of nodes and into the Node-as-Code that Ralph champions. Particularly when you get into forwarding.

> For example, if my PEP Tune node was actually a collection, and my dumb client published my tune to it, the collection might forward it to a different node. That node might be a default node that's part of the collection, or else it might be a unassociated node, which a bot listens to and republishes to a range of differently-ACLed associate nodes of the collection, carefully ensuring that to most people, I appear to only listen to some high-brow classical music, and therefore impress everyone.

	Could this be accomplished with PubSub Chaining (XEP-0253)?


More information about the PubSub mailing list