Category: IM Gateway


Thinking about Gateways

It’s been a little while since I thought much about my illustrious IM Gateway plugin for Openfire. My previous job kept me a tad too busy with other things for me to really have time for it, or be interested in spending my free time on it. Now, let me prefix this by saying I don’t have a lot of free time right now, and I may not for a while. That said, I had some time to step back and look at the IM Gateway plugin and think about some possibilities.

So first off, I don’t really know the state of the Py*t transports. Last I heard there was no one maintaining them really anymore. That is a shame as I was hoping to see them flourish outside my involvement. If that’s not true, then I certainly apologize — just know it’s because I haven’t kept up well. Regardless, I found that I prefer Java to Python for the most part anyway. So would I take those projects back if they were offered to me? Probably not to be frank.

But the IM Gateway plugin — The fact that it only works with Openfire I feel is a disservice to other server implementations, but overall it’s a very cool implementation that tackled some issues with external implementations. But if you need to restart the IM Gateway plugin, you have to take the server with it. Java seems to have a habit of being very plugin-able friendly but then easy to break things with it’s container. I’m seeing that with an application server I’m working with — it’s not hard for an app to break the application server.

So I began thinking about what core things the IM Gateway plugin does that the Pys did not. Primarily it revolves around direct internal access to user’s rosters so that things could trivially be kept in sync. Things being, nicknames, groups, actual rosters, etc. So pulling back I’m wondering how feasible it would be to do something like this:

1. Strip away the ties of the IM Gateway plugin to Openfire and make the implementation standalone
2. Take that stripped away part and turn it into a small “helper” plugin that works with the external gateway implementation to accomplish the same goals
3. Similarly, write a small “helper” plugin for ejabberd that does the same thing
4. What about other servers I don’t have interest/time to write helper plugins for? Well then the transports would act like any other external transport.

How would these helper plugins do their jobs? Well somehow they’d have to have open communication back and forth with the actual transports to manage rosters, maybe even intercept packets and munge them a bit. A little ugly but hey.

As you can probably tell, over the years I have never come up with some solution that could be formed into an XEP for all of this. At some level I continue to help that I’ll see the light through my experiments here, but I’m not holding my breath. In the meantime I’d like to see solid transports that work for everyone. Writing an ejabberd plugin would give me a real reason to learn erlang and really see what it can do.

Now, if you are someone who is excited about this concept, please understand that I don’t have a lot of time right now. I need to spend my free time on things that make me money for the time being and unless someone is dieing to sponsor this concept, I couldn’t put it ahead of other assorted things I am working on. That is not a beg for money, that is a statement of my situation and why I’m not diving into this “right now”. ;)

I would love to hear feedback on this btw.

External vs Internal Gateways, Round 2

You may have seen, in the past, my podcast about External vs Internal Gateways. In that podcast I talked about a number of benefits that internal gateways have over external gateways.

It’s not all peaches and cream though. You see, the problem with being so close to the internals of the server with internal gateways is that you tend to hear and trigger far more than you intend. I’m going to pick on Openfire a little here since that’s what the IM Gateway plugin is using. Some of these may simply be something that should be fixed in Openfire. Being one of the developers of Openfire, yes, I will investigate them when I can. =)

One of the issues is, when a roster item changes, I actually get a number of listener events that tell me this occurred. It’s difficult to know what the proper event is. In some cases, I’ll get an event with no groups and then another event with groups. Hard to know which one of those is true. ;) All things that I need to run through and make sure I’m doing things correctly.

Likewise, any time I tweak something about a roster item, I get events telling me it’s changed. Yes, I’m aware, I just did them. =) So in that case I need to ignore events.

It’s all very strange actually. I switched to listening for packets for real IQ packets coming from the client. Guess what, there’s a lot of IQ packets that come from the client. So that’s not really making things easier. In XMPP, groups don’t mean as much. Removing and readding groups is nothing big. In AIM and friends though, it’s dire. You remove groups and you’ve moved things around on your roster a lot. This is primarily because in XMPP, you have a roster item, and an attribute of it is what groups are in it. In AIM you have groups, and an attribute of a group is who’s in it. (for nitpickers, I’m referring to attribute here as “something the entity contains”, not attribute in the literal XML form of the word)

So if you were thinking, wow, internal gateways sound so easy! Think again. =) There’s a lot that goes on behind the scenes that’s more difficult to deal with than you might expect. So to sum it up, I’d like to simply say, there’s pros and cons of both. =) Don’t think an internal gateway is a magic bullet.

When Worlds Collide

You know, when you are working by yourself on an open source project, your schedule is your own. If you decide you don’t want to work on it for a couple of months, that’s your perogative. At some level there’s no rules what-so-ever aside from not doing things that will drive folk away from being interested in your project (assuming you care). One of the biggest things that drives the project, however, is what -you- want. When you are working on an open source project where you are teamed up with others, there’s some checks and balances over what you do and your partners do. However, at the end of the day, it’s the same type of situation, you all decide what the focus of the project will be. I don’t like to put it like this, but no one has a “right” to your time except for you.

When you start working with a company on an open source projects, things change. There are deadlines that the company is pushing for help drive your own timeline. There are things they’d like to see happen that you may or may not agree with. Instead of saying “well unless you submit a patch, it’s not happening”, you tend to work something out instead. It’s an interesting adjustment to “normal open source projects”.

Do I dislike either? No. In fact I’ve quite enjoyed the experience of it. It’s taught me a few things that I wasn’t aware of. Like I was rather blind to some of the requirements that corporations ask for. Some of the things they ask for I would typically have thought “that’s ridiculous” with some of my other projects, but here I see a lot of folk bringing the same issue up and I start to discover that the issue is more commonplace than I would have assumed. I’m not citing any examples here. Just suffice to say there’s things that having a broader knowledge of the corporate world has made me reconsider some of the decisions I might have made with other projects in the past.

So many thanks to Jive Software for giving me this additional experience that I wouldn’t have gotten probably with PyAIMt and PyICQt. =) It’s been fun and I hope it continues to be fun!

IM Gateway Plugin for Wildfire, and other things

Today we released the first beta version of the IM Gateway plugin for Wildfire. I’m quite excited to have a release out, but also a little pensive as I always am with a release. This one I’m expecting quite a lot of bug reports on because well, it’s an early beta and that is the way of things. I wanted to get a version out soon-ish so that folk could play with it and could start getting me some solid bug reports to work from. I never run into the same problems my users run into. ;) Always interesting to see things like… “my friend is using ICQ version 1 and I can’t receive messages from him!”

Anyway, I took a break from developing after fixing a last couple of bugs this weekend to make sure that I didn’t get involved in something that would temporarily delay the release. Spent some time on PyICQ-t in the meantime. Upgraded it to use James’s twistfix stuff and also to kill the pubsub support I was working on, since it wasn’t useful anymore after the recent updates to PEP. I would like to put out a new release of that soon. My typical “get everyone on the same page” release. Besides, right now they don’t work with Twisted 2.4. =/ (right now meaning, the current releases)

I have been feeling like crap for about a week so I think I may try to calm it down and just relax until I am better. No sense in making myself sicker. Besides, that will give folk time to comment. In the meantime I will do something leisurely like.. get out a release of the Pys. lol Why is that leisurely? Well because it’s already done, it’s just a matter of I need to put out the release. PyAIMt will be somewhat different in that I need to port over my bazillion changes to it. I may not dive into that until I’m feeling better. Then again, honestly, it’s kinda mindless work, so it might help to get my mind off being sick.