IM Integration with XMPP4r – 2 mistakes to avoid

In this 3rd part we’re going to be concrete but a little bit less technical. Here are 2 big mistakes you have to avoid when trying to setup an IM based application (Sorry for those who wanted more technical info about xmpp4r… maybe in the next one).
The #1 mistake : Trying to run XMPP4r under Rails
I’m not proud to say I did this mistake at first. Perhaps it’s because I was so excited to see xmpp4r in action that my head started making some strange electricity noises, thus short-circuiting my capacity to think rationally. Anyway, please, don’t try to put XMPP4r under your “vendor” directory believing it makes some sense… because it does not. You cannot make a XMPP robot in a Web context. The Web is stateless in nature. User ask for a resource, Apache kicks in and “tunnels” your request to some web framework, a response is returned to the user and then it’s over. (this was over-simplificated… but the main idea is there)
What we need here instead is something that runs on its own, something persistent, something completely independant of user requests on port 80.
So in order to build something out of XMPP4r, you need to create a separate program (in our case it makes sense to call it a listener) that will be running in permanence. But be careful because this could lead to mistake #2.
The #2 mistake : Putting business logic in the listener
I almost thought of doing this mistake but fortunately I didn’t. It would have been awful. Rails (or merb, or whatever) is your friend, you cannot ignore it and code your whole app in plain ruby! You want to get out of your XMPP4r listener as quickly as possible because it is not the “brain” of your application.
Try to make your listener as stupid as possible :

  1. Receives input (from a callback)
  2. Sends the data to a standard Rails application (data will be “understood” and “managed” there)
  3. Sends back to the IM user the response received from the Rails application

So basically the idea is to use the listener for IM interaction only and a Rails application for everything else. Said that way, some self-sufficient cool guys who like to show their attitude could be tempted to take a relax voice and say “Well, duh…”, but it might not be that evident for the rest of us.
So now you know 2 traps to not fall into… how you decide to design your application after that is completely up to you.