[Standards-JIG] jep-0060 $home
stpeter at jabber.org
Tue May 30 17:00:34 UTC 2006
-----BEGIN PGP SIGNED MESSAGE-----
>> How is ejabberd doing it? Would this help?
> In ejabberd the node attribute isn't an id.
> It's more a method like xpath or xpointer or directory+filename to
> access a node.
NodeIDs are opaque. They MAY have some structure but any such structure
is completely optional.
> Every user has write access to
> "/home" +servername+"/"+jidprefix+"/"+whateveryouwant
> Example: pubsub at jaim.at -> /home/jaim.at/pubsub/...
> There is a node "home" with a childnode "jaim.at"
> "jaim.at" has at the beginning no childnodes but the user "pubsub" has
> writeaccess to make a
> childnode with the name "pubsub" to the node "jaim.at"...
> If an instant node is generates it is generated as
> As long as a node is not additional assigned to a collection or an other
> node the node attribute is unique and makes sense.
> If nodes are moved, it isn't a good idea to take the node attribute as
> an id.
> I did not implement this, but I doubt they use the node attribute as an id.
> The "real" id is hidden.
> In jep-0060 I couldn't find the information that the node attribute is
> an id.
What do you mean by "id"? JEP-0060 stipulates that the value of the
'node' attribute is called a NodeID. By "id" do you mean something that
matches production  of the XML spec? See here:
> For me the ejabberd method makes sense.
> They didn't implement collections - but I still don't see the need for
> Collections are similar to directories in the filesystem.
> If a pubsub subtree is mapped to a big xml structure, collections make
Collections are, in any case, optional.
>> Would this help?
> Don't think so - but I don't really understand it.
> publish node='http://jabber.org/protocol/tune'
> looks like mixing namespaces and node name.
NodeIDs are opaque. See above.
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