Monday, after a long period of heavy development, I finally put out version 1.1.0 of the IM Gateway plugin! A total of 85 issues from JIRA were closed along the way and I'm quite pleased with the results. Along the way there were a number of stumbling blocks where I would just about be ready to release and something major would come up, and I certainly did not want to release anything with serious issues going on. As development continued, more and more features became interesting to me and were implemented. Since 1.0's release, I've had a number of helpful folk step up and offer patches, testing, code, translations, and help with libraries I depend on. I want to take a moment to thank everyone who contributed in any way! You are all invaluable to me! There are a number of big plans coming for the next major release, but I wanted to highlight some of the things from 1.1.0's release and even comment on some of it!

First off, there's XMPP/Google Talk support. One might ask, why do you want XMPP support when there's s2s? That's a question that's been fought many times in the past and typically results in nothing being decided. Well I decided to implement it and then another helpful person (thanks Mehmet!) took my piddly start with it and turned it into a full on transport for the plugin. After implementing it I found myself using it with some accounts I had seen no reason to add to my Adium X config but decided hey, if I can handle it server side, then I'll just carry it around with me. Has been working out really well!

Then there's Gadu-Gadu support. This is a protocol I did not expect to ever implement. Why? Everything about it is Polish. I couldn't find my way around the web site enough to even download a copy of the client. However, I said early on that if someone would translate or help me download or generally help me get it set up and there was a good API out there, I'd do it. So thanks to Marcin for stepping up and helping me get this started! The API itself was amazingly enough the easiest API to work with yet!

And what about SIMPLE support? Thanks to Ravin and Patrick for writing this support as I wouldn't have even known where to begin! I still don't understnad SIP/SIMPLE. Who knows if I ever will. But the transport sure works with my OpenSER server! I'm hoping some folk will take a look at it so I can get a feel for what it does and does not work with and maybe I can work with them to tweak it to work correctly with various implementations.

Another interesting thing that was added is an XMLRPC interface so site administrators can write their own web front ends for users to register with the various transports. That way folk could use some various standard web look and feel for the registration, and/or their own authentication mechanism, or even just something they consider "nicer" for their users, and dodge around typical requirements of registering through a client or requiring the admin to do it for them.

A lot of the inner workings of the plugin were redone, making things a lot more efficient in terms of network traffic and overall coding structure. I don't know that anyone but me will appreciate the reworkings of the code, but hey. =)

One of the interesting things that came about is that I ended up as the lead developer for Martyr, a very cool IRC library. IRClib just wasn't getting it done for me so I tried out Martyr, adored it's structure, and offered to help improve it. It's already led to a far better IRC transport than what I had before.

Beyond that I want to thank the folk from nimbuzz for creating the wonderful project OpenYMSG (a fork of YMSG) that fixes a number of problems I kept running into in the past! Through their improvements Yahoo support in the IM Gateway plugin was promoted to being considered stable! On top of that they've helped me out some with JML, the library that handles MSN support. Great work folk!

Well that's enough of me, I'm excited about things to come though and I hope you all will join me in that excitement and continue to help me with testing, ideas, and whatever! =)

The concept of transports is what brought me into the world of XMPP in the first place. At the time, I was tired of having to recall my usernames and passwords for AIM, ICQ, MSN, and Yahoo every time I switched to a new machine or IM client. The ability to store all of this information with a central account, on a server that I controlled, appealed to me on many levels. Upon setting up my own server and getting a couple of transports running, I discovered that XMPP itself is quite an interesting protocol. I wrote my own client soon after, and eventually got involved with writing my own transports for AIM and ICQ (PyAIMt and PyICQt, respectively).

Now, in the process of writing those transports, I continuously ran into frustrating scenarios where the transport just did not have enough access to the user's roster or session to do anything in a smooth manner. Some proposals came about, such as the unaccepted roster subsync proposal, and roster item exchange. The latter showed up, unfortunately, after it became a bit of a pain to incorporate its functionality into the existing code. Instead of sending roster items individually, the goal would be to gather them all up and send them in one big packet. The other bigger problem was that both this way and the old way would have had to continue being supported because I never did find a client that actually supported roster item exchange properly.

Unfortunately, all of the issues that come up affect end users, not administrators. I'm much more willing to inconvenience administrators than I am end users. For example, without roster item exchange, upon registering with a transport, a user gets flooded with subscription requests for every contact on their contact list on the other service. Now I don't know about you, but for me that's a lot of contacts. On top of that, the transport has to try to keep track of what items the XMPP user already knows about. It's not hard for this to get out of sync.

So Matt came to me at one point and asked me to write a plugin for Wildfire that would perform the services of the external IM transports, but be much easier to set up and work more smoothly. At first I balked at the concept of taking on yet another project. However, the opportunity to have an excuse to learn Java and being able to use internals to work around some of the bigger issues I get irritated with in my python based transports by using Wildfire internals was very intriguing. Since then I've come to gain a respect for, and even enjoyment of, Java. I adore the slew of well written tools, the wonderful IntelliJ IDEA software, and the wealth of documentation and libraries available for it. I'm quite pleased with what I've been able to do with the plugin that I was not able to do before.

That said, the unfortunate thing about working with non-open source protocols is that:

1. The protocols change without warning
2. The owners of the protocols don't typically want you there in the first place
3. Libraries written to handle the protocols are often incomplete

I've never really understood the resistance to others implementing and connecting to your service from non-official clients. I happen to believe in letting folk use whatever they want to use to communicate with each other. This means not only that I believe XMPP users should be able to communicate with AIM/ICQ/MSN/Yahoo/etc users using their own XMPP clients, but also that AIM/ICQ/MSN/Yahoo/etc users should be able to communicate with XMPP users using -their- own clients. I've never been one to quest for folk to "convert" to another protocol. So this is part of why I enjoy working with transports so much.

The IM Gateway plugin will continue to improve, on to version 1.0 and on further from there. I will try to improve the world of transports in general via new concepts (probably in the form of new XEPs). I will not forsake my external transports in the process as they also serve wonderful purposes. All in all, I'm pleased with how the future of things is looking and I can only hope others are as well.

I will be posting more here in the future as development progresses, both about the IM Gateway plugin, and about new concepts in the land of XMPP transports. As for the plugin itself, you can download the beta releases of it from Wildfire beta plugin page. I would also like to invite you to visit the IM Gateway Support forum and post any questions or concerns!