XMPP Gateways (or, alternately, Transports) are services for XMPP that let users sign on to other instant messaging networks (AIM, MSN, YMSG, etc.) through their XMPP account. So... you sign in to XMPP and the server signs you in to your other networks, and you can do all your chatting through just the one XMPP connection (Wikipedia has a nice diagram of this).
So I was wondering whether this would be a good solution for programming chatbots that work on many different IM networks. In Perl, the options for IM network connectivity aren't all that great at the moment; there is Net::OSCAR for AIM, Net::XMPP, and that's about it. Matt Austin and I were working on Net::IM::YMSG for Yahoo Messenger, but it's not that great yet (it can chat and accept add requests, but after accepting you don't see it online until the program restarts). For MSN Messenger, there's a dusty old MSN.pm module somewhere on the RiveScript forums that might still work but hasn't been updated in years.
I'm not very motivated to work more on Net::IM::YMSG because YMSG is dead to me. I created a new Yahoo ID recently, and made sure to opt-out of any directory listings, and it still gets add requests by spam bots on a regular basis. The ID is literally listed nowhere. I don't know how they find me. It is my opinion that nobody should take YMSG seriously anymore. I don't know anybody who uses it, so developing new code to use YMSG isn't worth my time.
With XMPP gateways though, one could just write an XMPP bot and let the gateways do all the work. Then you can have a bot sign on to AIM, Yahoo, MSN, ICQ, IRC, and even some obscure networks like MySpace IM, without needing to use native libraries for each protocol yourself. Sounds great, but I had some questions about how well gateways work (how many features they support per network, etc.)... so the best way to find out was to test it!
I installed the Openfire XMPP Server on my web server. Installation was surprisingly super easy. Basically all I had to do was this:
# apt-get install sun-java6-jre # dpkg -i openfire_3.7.1_all.deb
This installed it and automatically started it, and then I went to the admin panel port on my server to set it up. I didn't have to touch any config files or anything; everything was done through the web panel and was dead simple. I set up a Jabber user @kirsle.net and then I went out in search of a gateway plugin.
I found Kraken to fill the role. Installing this plugin was super ridiculously simple too, I just copied kraken.jar to
/usr/share/openfire/plugins and Openfire automatically saw it and extracted it and a new "Gateways" tab appeared in the web panel. Black magic. I later discovered that I could've just uploaded kraken.jar to a file upload field on the Plugins page on the web panel, too. This is, by far, the easiest server software for Linux that I've ever seen. I can't believe Openfire is free and open source.
So after setting the gateways up for the protocols that I care about, here is what I found:
For simple chatbots that only need to communicate over IM, XMPP gateways should work out fine. But if you have a native way to connect to a particular network, that method would most surely be preferred.
The reason I like the @aim.kirsle.net etc. suffixes on gateway usernames is because it would make it easier for a chatbot to distinguish unique users across multiple networks. In my Aires bot (which supports AIM and YMSG, through Net::IM::YMSG), and in all my older bots from years gone by, the protocol-facing code would format a user's name like "AIM-kirsle" or "YMSG-kirsle" before passing it to the main bot code. This way I could make an AIM user an admin for my bot, without any confusion about overlapping Yahoo IDs of the same name. Since the XMPP transports make a unique subdomain for each network, this can be used instead.
In conclusion, I think it will be worth it to add XMPP support to my Aires bot so that transports can be used for people who want them. Native support for a network is always preferred, but with transports you can easily put your bot on a lot more networks with very little effort.
This is a sequel to my rant about GNOME Shell. I decided to back up my claims with an experiment.
Installing gnome-shell in a virtual machine with no 3D hardware acceleration.
Every single desktop environment that exists right now will run just fine in a virtual machine with no 3D hardware acceleration: XFCE 4.6 and older; KDE 4.3 and older; KDE 3.x and older; GNOME 2.26.3 and older; LXDE; and of course all of the desktop-less window managers (IceWM, et cetera).
GNOME 3.0, I claimed, with its GNOME Shell, will be the first desktop environment that will not run unless the user has 3D hardware acceleration, and that there is no fall-back. Here is the proof:
* Fedora 12 Alpha (11.92 Rawhide)
* VirtualBox 3.0.6 r52128 (2009-09-09)
Let's launch it!
And... what happens?
Let's put on the dumb end user hat and say Joe Average installed Ubuntu 10.10 which might come with GNOME 3.0 and GNOME Shell, he hasn't installed his nvidia drivers yet because they're proprietary and Canonical can't legally include them with Ubuntu, and he logs on and sees THIS. He's lucky that X11 didn't crash entirely and send him back to the login screen, but nonetheless he can't see anything. He can't see Firefox to start browsing the web trying to find a solution to this problem.
Okay, let's move on...
Exactly the same.
I won't post screenshots because they look just like they did the last time. I get a mostly black, unusable desktop.
Of note however is that the terminal printed this upon starting the GNOME Shell:
OpenGL Warning: Failed to connect to host. Make sure 3D acceleration is enabled for this VM.VirtualBox knows GNOME Shell was requesting 3D support via OpenGL, and the guest additions driver gave me this warning. Let's move on...
I've personally not used it. But it is known to be buggy; VirtualBox labels it as "experimental"... well, here's why:
In this experiment, even with 3D acceleration by the virtual machine, GNOME Shell is not usable. Again, though, VirtualBox's 3D acceleration is still in the "experimental" phase. It probably doesn't work a whole lot better with Compiz Fusion, either. Plus my video card might just suck (VirtualBox basically passes the guest's OpenGL calls directly to the host's video card).
But the thing to take away from this is:
Now let's see if the GNOME dev team can turn this around in the next year (doubtful; they all come off to me as a bunch of eye-candy-obsessed children who'd rather snazz up the desktop because they think it's "cool" than to worry about things like usability, functionality, or accessibility... and with absolutely no thought given to the user experience, and no usability studies done, etc.).
GNOME Shell for the lose.