On 16-Sep-2009, at 10:36, Peter Saint-Andre wrote:
For the latter point I bring the following hypotheses to the table:
Every time somebody wants to start using pubsub collections (as it
is
currently defined), they really want to implement nodes-as-code.
Has anyone ever written up the node-as-code concept? I think that
would
be quite helpful.
Agreed. The only reason I champion collection nodes as I do is that I
don't know what "node as code" means. It might be better, but in the
mean time the only solution I have is collection nodes.
For me, it appears that static configuration of collections is
painful,
and services that want to provide nodes that aggregate other nodes
have
implicit rules for determining where stuff should go. So in spirit
that
would be kinda the same as collections, but without the additional
protocol and DAG theory.
Exactly. Simpler is better, if we can make it work. We must remember
that not everything needs to be defined in protocol...
I've always thought the DAG theory section of the XEP shouldn't be
there. The concept of collection nodes is relatively simple to anyone
used to hierarchies. The only added twist is many-to-many nodes, but
even that isn't particularly hard IMHO. Most rails-y web frameworks
have such a concept now, as do almost all ORMs. There's no need to
confuse people by letting them know there's math behind it.
I do like collection nodes because they are very generic and thus
allow many different configurations and uses. And while I don't think
we need to be pointing out "MATH HERE" in the XEP, it is a bonus that
DAGs are well studied and understood, allowing the motivated engineer
to do fancy math things with them.
-bjc
