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)?
-bjc
