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!

Anyway, there’s still “changes to the client” that need to be done to account for new transports. I don’t really care if it’s real code, simply icon sets, or whatever. =) Granted that’s a pretty cool way of handling it that y’all have, but I still think there could be something better.

you don’t have this issue in Coccinella)

* Service disco information is cached

* Theming of the roster icons works like this: user-$status-$gateway.png E.g. user-away-icq.png. If there is no such icon, it will fallback to the user-away.png icon.

The nice thing is that you can add icon support for a new transport without any code change in Coccinella. The only thing you need to do is to add the icons to the icon theme and change the themeInfo file.

So, if someone creates a transport for a new walled garden, he can add the icons user-online-danielchat.png, user-away-danielchat.png, etc. Then add “roster-danielchat” to themeInfo, and it will work! No coding involved!

<–you don’t have this issue in Coccinella)

* Service disco information is cached

* Theming of the roster icons works like this: user-$status-$gateway.png E.g. user-away-icq.png. If there is no such icon, it will fallback to the user-away.png icon.

The nice thing is that you can add icon support for a new transport without any code change in Coccinella. The only thing you need to do is to add the icons to the icon theme and change the themeInfo file.

So, if someone creates a transport for a new walled garden, he can add the icons user-online-danielchat.png, user-away-danielchat.png, etc. Then add “roster-danielchat” to themeInfo, and it will work! No coding involved!

* Coccinella uses the service discovery identities to see how to handle transports: http://xmpp.org/registrar/disco-categories.html (I believe Psi uses the roster item name so that you see the right icon for user%hotmail.com@msn.example.com but not for user%hotmail,com@msn2.example.com<–you don’t have this issue in Coccinella)

* Service disco information is cached

* Theming of the roster icons works like this: user-$status-$gateway.png E.g. user-away-icq.png. If there is no such icon, it will fallback to the user-away.png icon.

The nice thing is that you can add icon support for a new transport without any code change in Coccinella. The only thing you need to do is to add the icons to the icon theme and change the themeInfo file.

So, if someone creates a transport for a new walled garden, he can add the icons user-online-danielchat.png, user-away-danielchat.png, etc. Then add “roster-danielchat” to themeInfo, and it will work! No coding involved!

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 does this blog software not auto-link =( will have to do something about that.

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