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:
-
The protocols change without warning
-
The owners of the protocols don’t typically want you there in the first place
-
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!