Because development won't keep quiet

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.

7 thoughts on “Thinking about Gateways

  • john says:

    This will interest you: http://www.process-one.net/en/blogs/article/epeios_write_a_module_for_an_xmpp_server_once_run_it_everywhere/

    Actually, it is the same concept, but for ejabberd. So, you write the transports in Erlang and then use epeios to run them on other servers.

    PS: maybe you can use the existing Java transport code of Openfire. Get inspired by these URLs:
    http://www.theserverside.com/tt/articles/article.tss?l=IntegratingJavaandErlang
    http://www.erlang.org/doc/apps/jinterface/index.html

  • Hrm. If I’m reading that right you’d have to have erlang installed on whatever server you’d be running this transport on. Ideally I would not want to lead folk into installing stuff they don’t need. Like if you were running Openfire, that means you not only have to install java, but erlang now … just for this transport? Clearly a no brainer if you are running ejabberd since it would already exist, and jabberd2 and others, similar balls of wax to Openfire. I can’t see a good reason to make erlang an absolute requirement. The concept is interesting though, none-the-less, and I have enjoyed reading up on it.

  • As for epeios itself, there’s also Whack off of ignite realtime that would be effectively the same thing as epeios but completely in java. I mean at the end of the day it’s just the external component protocol, however it’s implemented.

    And part of what I was referring to with plugins for Openfire and ejabberd and such were to enhance beyond what the standard component protocol can allow me to do.

  • About the Py*ts, they’re actually doing quite well!

    r000n is building new releases from time to time fixing protocol issues and adding support for small features. He released version 0.8.1b3 today.
    The current versions of pyicqt are actually rather stable and do their job well. Looking around different public Jabber servers from time to time I’d say the amount of users of PyICQt & PyAIMt is still increasing, so both projects are still quite important for many users.

    The latest PyICQt can be downloaded here:
    http://groups.google.com/group/py-transports/web/pyicqt-0.8.1b3.tar.gz

  • That’s very excellent to hear! Thanks for the update man!

    — why does this blog software not auto-link =( will have to do something about that.

  • Our company’s choice in OpenFire was strongly based on the fact the IM Gateway functionality was available – even abstracting out the functionality and creating a thin plugin that realizes this abstraction would be helpful without having to go all out. This doesn’t help the language-specific problem…but what about CORBA!! (j/k). But the product works great, and we thank you for it.

    There is one functionality that we require, that I have been told others are looking for as well as posted on the OpenFire forums. We wish to integrate our OpenFire authentication with our existing custom app to centrally manage our accounts. OpenFire provides several hooks and I will be able to create a plugin to satisfy this (I’ll be creating a REST or XML-RPC implementation to permit others to do the same). We wish that IM Gateway either integrated user accounts with OpenFire (however, we understand the decoupled approach as well as the requirements of the IM Gateway) or it provided a similar WS auth approach.

    To this end, we plan on extending the IM Gateway to provide this functionality (managed through the existing Admin panel). I hope to provide this source back to the project to possibly be integrated with later builds but wanted to touch base with the creator/maintainers to know what we are doing and discuss our approach to ensure our vision is inline with yours. I haven’t drawn up the UML yet but will have it available soon to better show the concept. What is the best way to get in touch with the bodies responsible for this package?

    Thanks, hope to work with you soon.

    Steve

  • Why is my site not notifying me when new comments come in! GRR! =)

    Anyway, thanks for the kind words! Regarding integrated user accounts, I’m not sure I follow in regards to the Gateway plugin. Typically transports don’t require their own authentication mechanisms, and instead work with your existing XMPP server to figure out who you are. In other words, you log in as daniel@myserver.org (xmpp server), that’s what the transport sees you as, and there’s no other authentication needed. For all practical purposes, the transports are just acting like RSS feeds or something, where they are expecting you to come in and subscribe to them, and when you subscribe they ask you a few questions (account name and password for the legacy services, AIM or what have you) and then go from there.

    So with that in mind, I don’t understand where the IM gateway plugin would need to do it’s own authentication hooks with a central mechanism — unless it’s more of an authorization not authentication step. (in other words, the im gateway plugin would ask a central service whether X person is allowed to use it’s services)

    As for the bodies responsible for this package, if you mean the IM Gateway plugin and not Openfire itself, that would be me. ;) Feel free to email me or send me a message over XMPP (both addresses are the same). Openfire, the ignite realtime forums is probably your best bet!

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Current ye@r *