Chatterböxen Updates, Part the First

- -

UPDATE: I've put the code for my proof-of-concept websocket+sinatra server on my github.

As I mature as a person and as a programmer, I keep going back and updating my little projects so that the lessons I've learned and the new techniques I've picked up are best reflected. The past few days have seen that process happen with Chatterböxen. The process has not yet finished but I've been promising a blog entry about my progress so whatever.

Chatterböxen uses only JSON to communicate with the server now. This is one of those things that it was pretty silly I wasn't doing before. The version that's currently online uses a pretty ghetto and pretty unnecessary XML format to send messages to the browser. XML is one of those things. It was pretty trendy for a long time, and was the "X" in "AJAX" so I mean it was kinda a big deal or whatever, but realistically if you're not leveraging all the different stuff that you can bolt onto XML (namespaces, XSLT, whatever other crap there is—I'm not an XML guy) there's no good reason not to use JSON instead. It takes less bandwidth than XML, supports all the data types supported by Javascript's object literal notation (i.e., everything but functions), and is faster to interpret on the client side. For Chatterböxen it's a must, because the data being sent back and forth is so simple it doesn't really need to be XML.

The next Chatterböxen will use web sockets, when available. This is the big one, y'all. I have begun to write a new backend for Chatterböxen, a websocket server written with the EventMachine library for Ruby. Instead of the AJAX calls Sinatra handled before, most of the application logic will be moved into EventMachine. This will mean a much more responsive feel to the site, as you won't need to wait for the next AJAX request to come back to see new chats or events that happen. Also, the various race conditions associated with the asynchronous nature of AJAX (that's the first "A" in it, after all) will be a thing of the past. I currently have a working proof-of-concept that manages multiple sockets to multiple chat rooms and gives events for users entering/leaving the room. That code will find its way onto my Github account tomorrow, most likely. I'm still tinkering with it.

Websockets are a new feature proposed for HTML5, and I realize I'm jumping far ahead by supporting them now at this early date, but I believe that websockets are the ideal implementation for an application like Chatterböxen, they're how I would have implemented it if I had written it in Flash, and speaking of which for non-HTML5 folks there will be a Flash-based workaround when I'm done. As always, I do not in any way guarantee that this will look or work or feel the same in Internet Explorer.

The new Chatterböxen is more object-oriented, with a persistent data model. The old Chatterböxen used Memcache as its data store, essentially treating it like a key/value database. Aside from being inefficient—with each read or write requiring a serialize or unserialize of some complex data structure—this setup was volatile, meaning the chats were not guaranteed to stick around in memory forever. This was actually a feature of Chatterböxen, as part of its allure is the ephemerality of the conversation. My intent was never to have the chats randomly disappear, though, and due to various memory leaks I'm sure were in Chatterböxen's last revision, the memcache server would reset everything sometimes. Though a minor annoyance, this meant users were sometimes greeted with only the words "Welcome to Chatterböxen!" and nothing more, even though there had been conversations in there perhaps just hours before.

The old Chatterböxen also only used arrays and hashes to store the chats and all the information about the rooms and everything. Though this worked great, and was well-suited for the serialization I was doing in memcache, it's not really object-oriented. Ruby is a pure object-oriented language and I knew I could really clean up some of the semantics of the code by separating out this functionality into classes. I chose to include the DataMapper::Resource module in these so that I could take advantage of DataMapper, with a Redis backend attached to that. Redis is very similar to memcache but acts like a database and periodically saves its data to disk so that it's persistent. This is all part of my effort to make Chatterböxen a little prettier if prospective employers want to look at it, which I hope that they would.

It's a thoroughly useless web application, but I am extremely proud of it. Chatterböxen is the longest-lived of my projects, having been originally conceived the year I first moved to Chicago. The original Chatterböxen 0.1, written in PHP, was written shortly thereafter. The current incarnation, written using the Sinatra framework, in Ruby, is a couple of years old now and spent a brief moment as a Ruby on Rails app before I learned about Sinatra and realized it was far better suited for this. Chatterböxen is only about 300 lines of Ruby code in total. How awesome is that? Stay tuned for more, space cadets; it's coming.