Crisis Averted!

Keith Grennan recently described how he used Jabber::Bot to create an e-mail notifier, complete with code examples. Through a wicked combination of procmail, Perl, Jabber::Bot and Growl, he receives a sweet little notification when he's got new mail. Nice!

Jabber::Bot 1.1.1 is now available. This release includes a minor change to the listener thread that should improve CPU usage in some cases.

Some folks have directly or indirectly reported that Jabber::Bot tends to peg CPU usage at 100%. This is due to how the underlying Jabber::Simple framework handles incoming messages. Jabber::Bot 1.1.1 should alleviate these CPU usage pains in most cases.

Download:
jabber-bot-1.1.1.gem
jabber-bot-1.1.1.tar.gz

Jabber::Bot 1.1.0 is now available. New in this release is support for Jabber presence, including presence (available, away, do not disturb, etc.), status messages, and priority. There are several other additions, changes and fixes in the full release history.

Despite my best efforts for a bug-free initial release of Jabber::Bot, a few choice issues found their way in, including one line of debug code. Oops.

With that, Jabber::Bot 1.0.1 is now available. Fixes include the removal of said degug statement, and two regex fixes. The release history has all the details.

Jabber::Bot makes it simple to create a Jabber bot with little fuss. It is a perfect starting point for creating and customizing a powerful Jabber bot, public or private. A Jabber::Bot's command repertoire is a combination of regular expressions and pure Ruby code. With a little creativity, there's really nothing a Jabber::Bot can't do.

For example, I recently created a Jabber::Bot that interfaces with a custom Lace chat room I extended with a RESTful API, and it's been working great.

Installing Jabber::Bot is a snap with RubyGems: gem install jabber-bot.

You'll find some brief documentation with examples on the Jabber::Bot home page. Also, the RubyGem contains full RDoc, and the gzipped tarball includes a sample Jabber::Bot implementation.

Update: (1 June 2005) The information in this article is now out of date. Lace development has changed directions slightly. Read about it here.

My recent development experiment, Lace, an 'Ajaxian' web application, has raised many questions as to what exactly Lace is, what it does, and why it exists in the first place. Rather than trying to explain Lace via the Lace demo itself, this article intends to shed some light on the Lace project, from its beginnings to its many possible futures.

In The Beginning

The idea for Lace came from many years of maintaining a very small web-based 'chat' room (10-12 users), mainly for my friends and colleagues to use when bored at work when IM services arebeing blocked by evil sysadmins. It was a small project, but working on it was something I loved to do; it had the bonus of garnering praise from my (mostly non-developer, non-designer) friends who used it nearly every day.

The features were minimal, but my little chat room looked good, and did its job very well. I was constantly thinking up ways to improve the back-end, either to ease in maintenance or to add/change features.

Ajax For Everyone

With all the buzz surrounding XMLHttpRequest (or Ajax, if you prefer) and the release of the stunning Google Maps, it finally hit me (after years of avoiding it) that JavaScript was nearly ready for mass consumption. With 5th generation browsers on their way out more than ever, and cross-browser DOM support becoming less brain-bending, the power of JavaScript (and more specifically, the XMLHttpRequest object) was a viable option for developing usable web applications.

Chat, meet Ajax. Ajax, chat. But there was more to it than that. The growing acceptance of XMLHttpRequest (be it a fad, or not) made that tiny little yellow light bulb above my head slowly light up, and the development of Lace began.

What is Lace?

Lace is not necessarily a chat room (though in its current incarnation it is being demoed as one), or a chat server, or anything related to chatting or instant messaging. Lace is the application, or framework, that the demo chat room is built upon -- a simple, open communications framework. The idea behind Lace is to allow developers to easily create web applications that consistently and continuously share data between multiple clients over HTTP. Chat rooms, RSS readers, 'rich client' web applications, server to server communications and distributed services are just some of the possible uses of Lace.

But Lace Clearly Is A Chat Room!

Lace's initial release is a simple chat room, yes. The chat room is my initial experiment, a proof of concept, to get my bearings and determine the best way to turn the idea in my head and notes into a working application. Lace isn't the chat room, but the ideas and expectations of the framework behind it.

Lace's Current Inner Workings

At Lace's core is an HTTP polling mechanism. That is, the client repeatedly connects to the server looking for changes in the data. If there is no change, then nothing happens. If there is a change, then the new data is fed to the application. This polling mechanism is dynamic. If a client shows no sign of activity beyond the automatic polling cycle, the polling interval slowly becomes larger. After a short time, it is possible for a client to stop polling altogether, and no more communication with the server will be possible until it is manually switched back on.

This dynamic polling mechanism has two side effects. The first is reduced HTTP communications back and forth to the server. Bandwidth is saved by only transmitting necessary data rather than the entire page. Additionally, by dynamically lengthening the polling interval, inactive clients become less 'greedy' over time. The second side effect, is that once a client has stopped polling it is essentially dead to all communications until switched back on. However, there's nothing preventing Lace from polling on into eternity if you so choose.

Of course I should mention that when data is submitted by the user, Lace immediately returns an appropriate response outside of the automatic polling cycle.

The alternative to clients repeatedly polling the server looking for changes is server push. With push, the client-server connection remains open and data is transferred when necessary. However, this has the side effect of bogging down the server with multiple open connections, affecting all clients with the decrease (or lack) of performance.

Because of the potential for server meltdown with push methods, it is my opinion that server polling, especially dynamically variable polling, is a more scalable solution to the problem of quickly and consistently updating clients with new data.

Walking the Walk

Sure, the ideas behind Lace are all well and good, but will it work? Will it be a viable solution to anyone's problem? Will it even get off the ground? I just don't know.

A recent backlash against XMLHttpRequest 'breaking the web' for similar reasons to the anti-Flash sentiment of a few years ago may steer Lace's future. (Usability is key on the modern web.) Or perhaps because of the enormous attention 'Ajax' is getting, it will no longer be 'in style' in a few months, and passed off as a fad. (Possible, sure.) Maybe someone, somewhere, has already developed a better alternative to XMLHttpRequest and we just don't know about it yet. (Very possible.) Or, maybe I simply decide that Lace isn't turning out the way I had hoped and it gets scrapped. (It wouldn't be the first time someone ditched an idea.)

Happy Endings

No matter what happens to Lace, and above and beyond anything else written here, it is the experience of creating something (whether viable or not) that drives me. So in that regard, I'm happy.