On Mon, 2009-11-23 at 14:06 -0700, Peter Saint-Andre wrote: > On 11/23/09 12:22 PM, Kevin Smith wrote: > > On Sat, Nov 21, 2009 at 3:08 PM, Robin Collier <[email protected]> > > wrote: > >>> Collections as I see them are really just abstractions of content-based > >>> pubsub systems (hi Bob Wyman!), where you basically assign a fixed name > >>> (node identifier) to a particular query into the notification plasm. I > >>> am still interested in explicitly defining the minimally subscribe-able > >>> unit (like a blog post), so I want to to pass along a specific node from > >>> where a notification originates, though. > > > >> That is an interesting concept, correct me if I am wrong, but this sounds > >> an awful lot like a view in a relational database. I am not sure if I > >> would > >> consider this to be a collection though, it seems to me like another > >> concept > >> which would be better called an aggregation node. I guess I would > >> distinguish them by defining a collection node as a collection of nodes, > >> whereas > >> an aggregation node is a collection of items from multiple nodes. > > > > When I read this thread, I'm left thinking that we've got two things, > > collections as they're currently known, and pesudo-nodes, or > > node-as-codes, or cold-nosed-bodes, or whatever. I'm not actively > > writing these systems, though, so I'm not sure. Can anyone say that we > > definitely do, or definitely don't need to distinguish between the two > > types? > > We do seem to have a bit of a disconnect here. I'd like to either bridge > the gap between collections and "node-as-code" or decide that there > really are two separate things here. Right now I lean to the latter.
I tried to explain my view on this today in another part of this thread. Basically the subscription and notification parts would be the same. The mechanics of how nodes are created, associated with collections and administrated, and how notifications are generated differ. I want to note here that I have been focusing on the node-as-code use case where the items are also part of so-called (origin) leaf nodes. Just like with collections, you want to know which origin node a notification is from (this is provided by the 'node' attribute on the <items/> element in the event message), and what subscription(s) caused you to receive it. Maybe this is really an edge case, but it requires fixes to some of the same issues XEP-0248 has right now. I would love it if we could converge. That said, I'm having trouble seeing the usefulness of having 'regular' collections, and justifying the complexity of node maintenance and notification logic inside pubsub services that comes with it. For completeness, the other case is where the node-as-code is really a leaf node. In /that/ case, the only difference with 'regular' leaf nodes is that there are no explicit in-band publish actions. This can be done with XEP-0060 as-is. > BTW we must find a way to use the phrase "notification plasm" in our > specs somewhere. :P :-D ralphm
