[ejabberd] About current pubsub implementation

Jehan Pagès jehan.marmottard at gmail.com
Thu Jun 19 20:02:39 MSD 2008

> 1/ Why force people to make nodes of the form home/server/username/... This
> would make sense for PEP, as it is "Personal". But for the generic pubsub
> implementation, it does not make sense in my own opinion. I don't see why a
> publication node MUST be associated to a specific login. First you may want
> that people do not know your personal jid and still provide them with a
> publication node. Or simply a node can be used for publication by
> multi-publishers. A common example would be a general website with many
> publishers.
> Anyway I don't think this is good. You may provide the Jabber server
> administrators with a way to restrict the node names if they want. But I
> really don't understand why it is done here at the software level (so no
> other configuration).
> It is a good thing because, it is otherwise a mess. Imagine a server with
> millions of registered users. You quickly end up with hundreds of thousands
> of nodes in a flat hierarchy which is a mess.
> Think about it a file system on a Unix system: It is easier to manage users
> data with home directories than to put all data for all users in the same
> directory.
> You also avoid name clashes.

A Unix system ok... because you have a lot of stuffs that the user cannot
and MUST NOT access. You have data, binaries, libraries, etc. and finally
the user personal files, hence the /home directory.

Here in a pubsub tree, you have... nodes! Only. Nothing to protect, no
system files, just the user data. So whatever, you are only moving the
problem from the root / to home/. So of course you may want to organize your
tree in order to have all the blog publication on one place, the
notification of your alert system on another, etc. But then you should let
the admin of the server to decide by oneself whether he wants to protect
some parts of the hierarchy, or some other give only access to some limited
named users, etc. For me this should clearly be an administration decision,
not a development one.

In general, I think the home/ is a bad idea for the "general" pubsub
implementation especially because I want the possibility to not associate a
node with a jid. I gave reasons of privacy + multi-publishers nodes. And I
am sure there could be plenty of other reasons.

And about the name clashes, that's how all the web service providers work:
first arrived, first served. When a server provides hosting services, then
you have a good name because you are first.

Of course I don't think the proposed idea (with home/ system) is bad, I just
say that it should be configurable and that every organization should be
possible if wanted.

> Anyway, our pubsub implementation is pluggable so you can rewrite your own
> hierarchy plugin if you want.

Ok. If I have some time and if you really don't agree with my proposition of
extensive configuration, then I may try to do this. Do you have some
documentation on plugging your pubsub module?

> 2/ What is this special node pubsub/node? It says it containes "all other
> created nodes". But if I create a node in my /home, I don't see it in
> pubsub/nodes. And I cannot create anything in pubsub node. So what is it
> exactly?
> It is for global pubsub nodes (created by admins). I am not sure if it is
> still used however.

Ok. I think I tried once with an admin user to create nodes in there without
success. But I am not sure of it. I will make new tests soon.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jabber.ru/pipermail/ejabberd/attachments/20080619/d8d0ea30/attachment.htm 

More information about the ejabberd mailing list