[Standards-JIG] JEP-0060 Publisher Model - nodehirarchypermissions

[Peter Saint-Andre]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

bernhard wrote:
> Hi
>>> 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
> bug"

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
collection nodes.

Peter

- --
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEfM06NF1RSzyt3NURAnAsAJ9VZ09f8NBdrAZhHqmP+MBnJprASwCgrppG
cQuIASeqQq+75AeZ4TBmoMk=
=RTpr
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3641 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20060530/81c34096/smime.bin