PubSub Hierarchy Ideas

Work in progress

jep-0060 describes event notification very well. ejabberd has some really good interpretations of the standard.

Here some thoughts about pubsub hierarchy

Store Config Files
Most of the jabber clients are configurable. If you work on a different computer, you have a different configuration. At least parts of this config could be stored in pubsub.

XML Wiki
Like wikipedia is for humans, pubsub could be the wikipedia for maschines. PubSub could be the storage of human knowledge in maschine readable XML format.

Storage for Websites
jep-0124 makes it possible

Filesystem analogie

 * nodes: files, links
 * items: time based, history of file like in cvs, rss,..
 * collections: directorys

XML analogie
Think of one big worldwide XML file that is accessable using a XPath like query language


 * time based
 * links
 * notifications
 * performance

XML database analogie
pubsub is an xml database.

Make it simpler
Unify Collections and Nodes. If a node may have child-nodes and child-items at the same time, there is no need for collections.

There should be a node that is possible to access if you know the jid of a user. Think about $home/.application/config as in Unix like systems.

ejabberd 1.0 implementation (bugs)
In ejabberd collections are not implemented. The way child nodes are assossiated is not good because of the id isn't an id in the sense of an id in Database systems.

The "name" attribute of a node should be the only human readable property. The id could be something like "df234rqsdsdf435r234df" without loosing information.

It seems like ejabberd did not user the node attribute as an id. Internal they use a diffent id. The node attribute could be a concatenation of the names of all ancestor nodes seperated with an "/". The node attribute discribes an xpath.