[Standards] Why XMPP is going on the wrong way for Pubsub commenting
binary at jrudevels.org
Wed Jul 4 09:37:16 UTC 2012
On 07/04/2012 02:42 AM, Tim wrote:
> I'm Jaussoin Timothée, founder of the Movim project (http://movim.eu/),
> about 4 years ago we make the choice of XMPP for our project. With the
> important decision to use Pubsub for the stream of our users.
> Since I've read and learn a lot on XMPP and Pubsub to implement cleanly
> in Movim.
> We also make the choice to use XEP0277 (microblogging) for our stream
> implementation, with the commenting part.
That's a pretty good choice but don't forget that the XEP is still
experimental and WILL be changed in non backward compatible way.
> Yesterday we have launched the 0.5 version of our project with the full
> integration of 0277 publication+subscription+reading, also for the
> comments part.
> Our XMPP server (ejabberd) have, since, big problems to support the
> traffic and the request of nodes creations.
As I already said that is completely problem of ejabberd pubsub
implementation and not the approach itself. I faced with the problem
long time ago and did some research about this diving into the ejabberd
sources and mnesia mechanics and found that ejabberd's mnesia db schema
is very inefficient. I've posted a ticket to ejabberd's tracking system:
https://support.process-one.net/browse/EJAB-1461 but it was closed with
a comment that it will be fixed in ejabberd-3. So you have three
options: wait for ejabberd-3, use ejabberd-3 alpha, use another
jabber-server (but I don't know any good implementation which I can
advice). Also, you can try use mod_pubsub_odbc, it should work better
but I am not sure.
> For each message posted on Movim, our plateforme create a new "comment"
> node on the Pubsub server. It's dirty and fool !
It's too rough. It would be better if you will explain in details what's
wrong with this approach keeping in mind that your problems are related
with inefficient pubsub implementation. Try to understand that even if
we will cut these nodes, we will face with the same problem when we will
grow in users. Too few users will be needed to slow down the ejabberd's
The problem is actually deeper: we, actually, have no any good
application level protocol that uses pubsub features deep. All that we
have is a simple singleton nodes that don't consume much power. So
implementation have no stimulus to be faster, more powerful and stable.
We have all chances to make XEP-0277 to be such protocol, I think, but
we have to unite our efforts.
> I've also read the XEP0303 for this issue, and using a
> "comment.pubsub.com <http://comment.pubsub.com>" server to post and
> retrive comments is, for me, the wrong way.
> Why is it so difficult to create a simple XML tree who sum up all the
> informations of a post, including its comments !
Because it completely alien to the nature of pubsub and is not flexible
1) how other people can post comment to the node them have no
permissions to post?
2) how would be efficient such way with a long topics?
3) what if I want to have different threads for the same topic but in
different languages or for different audience?
> With this implementation, you only have to subscribe to a single node.
We can imagine a simple system to subscribe to a item itself without
subscribing to the entire node.
What if you DON'T want to receive all the comments but you want to
receive events for new posts?
> <pubsub xmlns='http://jabber.org/protocol/pubsub'>
> <publish node='urn:xmpp:microblog:0'>
> <item id='1cb57d9c-1c46-11dd-838c-001143d5d5db'>
> <entry xmlns='http://www.w3.org/2005/Atom'>
> <title type='text'>hanging out at the Café
With best regards,
XMPP Developer and JRuDevels.org founder.
More information about the Standards