[Standards-JIG] JEP-0060 Publisher Model - nodehirarchypermissions
stpeter at jabber.org
Tue May 30 22:54:51 UTC 2006
-----BEGIN PGP SIGNED MESSAGE-----
>>> The node hierarchy ejabberd has, is not a bug. yes/no
>> It sure seems that way.
> ejabberd has no collection nodes but "normal nodes" that are not "leaf
> nodes" and not "collection nodes".
> This nodes have "normal nodes" and "items" as child nodes.
This sounds odd.
> A "normal node" does not exist - if I understand your answer.
> In my question - because I thought that it is NOT a bug - I asked "NOT a
I would say it is a bug.
> If it is a bug, this makes no sense for me.
> Why have collection nodes and leaf nodes?
> Why not unify that?
Because that's the way we designed it. Many systems don't need
collection nodes (which you can think of as directories). They can
simply use a flat structure. Collections provide hierarchical structure
on top of the minimal pubsub use cases.
> In a filesystem there are directories and files.
> In pubsub we have "directories", "files" and "items".
> "directories" are spezial files - in XML world we don't need that.
> Think about mapping XML - PubSub subTree.
> Or navigation through a pubsub graph.
> Do we really need a leaf node the is called "index.pubsub" (like
> index.html) ?
We have a root collection node, which I think is what you want.
> A "node" is not extensible if it is not possible to make a child node of
> this node.
> A "leaf node" is the "item" I thought.
There are two kinds of nodes:
1. Leaf nodes. Items are published to these and they generate
notifications. (An item is not a node!)
2. Collection nodes. We can associate leaf nodes with these, or other
Jabber Software Foundation
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3641 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards