Trials, Tribulations, and Transports

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!

I think the biggest reason why Microsoft/Yahoo/AOL want you to use their official clients is because of the advertising. Think about it for a moment, if you were in Microsoft’s shoes, and you have 200 million users on your network, wouldn’t you want to make them use your client (which has ads), and thus bring you revenue?

That said, I think it’s a very shortsighted approach, and will ultimately fail. The tighter your grip, the more that slips through your fingers, especially as you can get clients Ad-free.

“I???ve never really understood the resistance to others implementing and connecting to your service from non-official clients.”

It’s simple: advertising profits!

btw: is there a ROADMAP or future plan for the external Python transports? It seems these projects are stalled

Hrm. Yeah I do see your points about advertising. I guess that’s the reason I left their clients in the first place. I used to absolutely adore ICQ until it turned from a wonderfully elegant client to … something that seems like chat is an afterthought. Clearly we need an advertising XEP. ;D hahaha kidding!!!

sander, there is no roadmap for my python transports. It’s always been a “work on it when I have time thing”, and said time has evaporated as of late. That said, I posted to the py-transports list asking if there was any interest in other developers coming on and helping with the projects and I got little or no nibbles. The only nibble I’ve gotten is one that may or may not happen, nothing definite. I don’t intend to let those projects die, but I also don’t have time to put into them right now. I can only hope that some folk will step up to the plate and help me out. =) (obviously I can only speak for PyAIMt and PyICQt)

“Clearly we need an advertising XEP. ;D hahaha kidding!!!”

Why not? Seriously…client then can have a check box “Do you want to see content based adverts in the interface?”

You know, I must admit I considered writing one at one point. Both as an April Fools thing and… not as an April Fools thing. =) I mean, such a thing might actually lead some other companies to writing XMPP clients and switch to XMPP. I mean you never know, AOL might give you the “AOL Blessed” XMPP client. Maybe I should actually bring that up on one of the lists.

Who would willingly accept content based advertisements? If I had that check box I would immediately turn it off.

Google might like to implement this feature, you never knows

Hi Daniel,

@“Clearly we need an advertising XEP”

In my opinion it’s XEP-0060 which is alredy implemented in Wildfire.

Maybe you want to extend your gateway pluing to query the providers for ads and publish them within Wildfire.


laugh I didn’t imply that I -wanted- to add advertising support to the plugin, did I? =) Either way, good point, pubsub would be a great way to handle advertising if someone wanted to add it.