chat application: pubsubhubbub vs xmpp

Question

I'm unsure on the best stack to build a chat application. Currently I'm thinking of two main options:

• facebook tornado
  • cons: does not use the main chat protocol xmpp but pubsubhubbub
  • pros: i really like its simplicity for development (webserver + webframework); pubsubhubbub also seems simpler as a protocol than xmpp; and i know python
• xmpp + bosch, punjab, ejabberd
  • cons: don't know erlang; overall seems a bit harder to develop
  • pros: uses xmpp protocol

The chat app will need to have the following:

• Private messages
• Public rooms
• Private rooms
• Chat history for rooms (not forever, just the last n messages)
• html embedding
• url to chat room

Both options seem scalable so that's not really my worry (we're thinking of running the app in amazon's ec2 as well). I know there's a project that builds a xmpp server using tornado but it's not ready for production use and our deadline isn't that big. Basically my main worry is ease of development vs somehow regretting later using pubsubhubbub to develop a chat app but I read somewhere that PubSubHubbub might eventually replace XMPP as REST replaced SOAP - so what do you think?

Answer 1

Go for XMPP.

Out of the box, ejabberd has support for all your requirements. You won't need to see any erlang and write custom modules for ejabberd. And with Strophejs, XMPP in the browser (which is what you are apparently doing) is great.

For your last question about pubsubhubbub replacing XMPP, don't count on it. XMPP is over 10years old, solid open source and proprietary interoperable implementations both on client and server, and is elegant so it won't go away.

And you are developping a chat application which is what XMPP was made for.

Answer 2

Facebook Tornao doesnt use PubSubHubbub at all!

Go for XMPP, it's been designed for what you're looking for. Tornado wasn't designed for that specicically, but for long polling requests in general.

No need to use Punjab, the ejabbed http-bind module does a pretty good job now. Also, you don't need to learn Erlang, the same way you don't need to learn C when writting a webapp that uses Apache :) Check out stuff like Aristochat. The only thing you'll need to play with is the configuration of your XMPP server and chat rooms, and then, Javascript for the client side (in the browser).

Answer 3

If you don't need federation via XMPP but do want to prototype and deploy quickly along with scalability out of the box, take a look at the Lift web framework's example of a chat server in one page of code.

Answer 4

PubSubHubbub(PuSH) was never meant for chat apps in the first place. It is sometimes referred to as the "IM for the Web". I would suggest you go through this slide: Realtime Ruby for the Realtime Web by igrigorik

The question really is how realtime you want to get? If you want speed then XMPP is the best option.(500ms) while PuSH depends on your feed and how its relayed. Remember, with PuSH its a total of 4 network hops before the content reaches the subscriber.

The even bigger trouble is PuSH relies on HTTP Post. Even if you do end up designing a chat app based on PuSH, and say on a later stage, you want to make it available to other devices or even as a desktop application you would have to relay the same content using XMPP. The other place you will be losing out on is that it would be very difficult for your chat app users to login from any other IM of their choice.

Answer 5

You could use a REST API with WebSocket to implement a Publisher/Subscriber architecture.

Atmosphere and swagger sockets are nice java framework that you can plugin into your Jersey REST api and achieve this.

The blog of the creator of Atmospehre, jfarcand, has one example of chat application built with these technologies.