node as code sounds a LOT like a javaspaces to me, I like the idea but
if thats what you want, why not just use openspaces? or at least
something akin to the javaspace api?
Peter Saint-Andre wrote:
On 11/23/09 2:06 PM, 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.
It seems that it's time to make an executive decision.
I've had a chance to read the complete thread about collection nodes.
Andy Skelton's description of node-as-code in use at WordPress.com is
compelling. It works for them, and seems to work well.
Brian Cully's description of collection nodes in use at OnSip.com is
also compelling. It works for them, and seems to work well.
Because both approaches seem to work well, I'm leaning even more heavily
to the conclusion that both are equally viable, and that they might even
be solving different problems. I see no harm in allowing the collection
node work to proceed and pursuing improvements to XEP-0248. Therefore I
propose to make Brian a co-author of XEP-0248 so that he can move it
forward with help from me since I am one of the authors.
Ralph Meijer is also a co-author of XEP-0248 but it seems that he might
not want to keep working on it (since he now seems to prefer the
node-as-code approach). Again, that's fine, and even if Ralph doesn't
want to keep contributing to XEP-0248 we'd keep him on as a co-author.
Perhaps in the future we'll decide to find a bridge between collection
nodes and node-as-code, but right now I think there's no objective basis
for picking one over the other, so I think we need to pursue both in
parallel and see where they lead.
Peter
