Difference between revisions of "PubSub Hierarchy Ideas"
Neustradamus (talk | contribs) m |
(No difference)
|
Latest revision as of 01:36, 17 December 2020
Work in progress
XEP-0060 describes event notification very well. ejabberd has some really good interpretations of the standard.
Here some thoughts about pubsub hierarchy
Use Cases
Store Config Files
Most of the XMPP 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
XEP-0124 makes it possible
Systems with hierachy
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.