August 30, 2008
julien
Comments (3)
Trackbacks (0)
Architecture, Instant Messaging, Pidgin, Technical
developer
412 views

Switch from Jabber Gateways to Libpurple

This week have been pretty intense! While it started preety smoothly, very soon it appeared that our current instant messaging architecture, based on Jabber gateways was not ready to handle the users that the widget generated. Here is a little review of the steps that I’ve been passing through for the instant messaging architecture, with the great help of Pidgin and Libpurple!

Initially, I thought that I should create a bot for each “messenger flavor” with the existing source code libraries that you can find on the web. Very quick I discovered that this was a bad approach : no way to reuse code between each bot (different libraries, and even different languages). This would make development fairly tough and not very maintainable!

The second step was too switch to Jabber/XMPP and use the gateways that almost any server provides. The good news was that I would then only need one bot (jabber) and that this bot would be able to send messages to any gateway! The bad news is that these gateways were made for “regular” users and not for bots, which means that they are not very scalable and not able to send some messages. Furthermore, it was also almost impossible to know if a single gateway fails, while the other were still running! Finally, it’s not very scalable because if a single flavors gets “clogged”, we need to relaunch a bot that will manage all flavors again, and not just the one that’s overloaded!

After some researches, I found Pidgin and Libpurple; and I think we’ve got a good solution here! With the same code, we can make a bot for each flavor… And also, it’s C, so it is pretty fast… Bad news, I don’t “speak” C very well, so we’re hiring In the meantime, I am making great use of Ruburple, a Ruby binding for Libpurple -even though there is no documentation and it’s not maintained anymore! Another good news is that Notifixious will very soon support a ton of “exotic” IM protocols, such as Gadu-Gadu or QQ…

No Related Post

Viewing 3 Comments

Olivier 2 months ago 1 point
Please login to rate.

Do you already have an account? Log in and claim this comment.

Where I work we are also investigating libpurple too but for QQ essentially (Chinese market).
But our architecture is based on PHP so we are using PHurple. So far it's pretty easy.
The only drawback is when something change in the protocol you have to rely on the libpurple team (it's should be fine with the main IM protocol but QQ for instance is a really big black box)
Our development is not live yet so I can't really give you any feedback on the scalability, Hope it will scale better than Jabber gateway.

reply edit reblog flag record video comment

julien 2 months ago 1 point
Please login to rate.

Do you already have an account? Log in and claim this comment.

Hi Olivier,

Thanks or the insight. I am definetely gonna implement QQ for the chinese market... By the way, anyone has accurrate usage statistics for IMs in the world?

Concerning LibPurple, my feeling is that it's is somehow better to create a native C application than using the various wrappers. What do you think?

reply edit reblog flag record video comment

http://www.ouvre-boite.com

lineage 2 adena 2 days ago 1 point
Please login to rate.

Do you already have an account? Log in and claim this comment.

Where I work we are also investigating libpurple too but for QQ essentially (Chinese market).
But our architecture is based on PHP so we are using PHurple. So far it's pretty easy.
The only drawback is when something change in the protocol you have to rely on the libpurple team (it's should be fine with the main IM protocol but QQ for instance is a really big black box)
Our development is not live yet so I can't really give you any feedback on the scalability, Hope it will scale better than Jabber gateway.

reply edit reblog flag record video comment

http://www.mogs.com/lineage-2-adena