Facebook Chat
Facebook’s new Chat feature certainly took me by surprise, but after a few minutes of using it I realised this was the smartest thing they could have done. It gives the whole “Facebook Platform” a new sense of immediacy, thus enhancing more or less every aspect of the site by adding the element of interactivity. (Eg, you can make a “witty” comment on a friend’s photo and immediately get an irate response from them.) At the very least, it’s caused me to spend more time looking at Facebook pages in the last couple of days than I had in the last month combined. I’m interested to see where this takes them, and if it can rejuvenate the platform whose user-base seemed to be suffering Facebook-burnout.
Social aspects aside, the technical implementation is rather clever. The one thing that made me go “buh?!” was the apparent persistency of chats across multiple windows. They make it seem like they are somehow able to preserve state between pages, but after some delving I found that they achieve the effect through some neat tricks.
When you open a Facebook page, your chat’s “state” is sent along with the main page data. They then make an GET XMLHTTPRequest to a specially-configured HTTP server. This is accepted, but the server delays its response until it has something to send (ie if there’s some change in state, like a message, or a user going on/offline). If nothing happens before the request times out, then another request is made. This effectively establishes a channel through with the server can “push” content at the user. I presume this is the same way that GTalk, MSN Web Messenger, and other similar web apps do this – although I’ve not personally investigated them.
As to persistence: If multiple browser windows are making GET requests to the same URLs, the browser’s internals will only make a single connection and serve the resultant content to all of the requesting windows. (the same way it would only download an image once that appears on several pages) When you send a message from one of your open windows, any others are then notified via the established “push channel” (not sure what the correct name for this is), keeping them in sync. If things go awry (connection issues, etc) an instance can POST to ‘history.php’ to refresh its state. This cleanly avoids out-of-sync issues that could conceivably plague such a system.
This all gives the illusion of a persistent chat application that spans multiple windows, and so far it seems to be pretty fault tolerant. Colour me impressed. It will be interesting to see if and how they decide to open this new feature up to developers via their API, although I’m fairly certain it won’t compel me to install any new Facebook apps in the near future.
Update: It happens that this technique has a name: see “Comet” at Ajaxian.
May 7th, 2008 at 6:17 pm
immediacy is everything, you’re dead right. twitter seems to re-teach me that lesson every day. i guess facebook worked it out when they saw so much twitter conv happening through their platform. highlights the risks building apps for networks/platforms.
May 22nd, 2008 at 1:44 pm
Netscape and descendants supported an x-mixed-multipart-replace mime type on content, down which you could chunk an arbitrary number of messages, waiting arbitrary amounts of time between each. I have no idea how you’d get to it through DOM, but it made for great webcam…
May 22nd, 2008 at 2:10 pm
@Mikolaj, some browsers (maybe only Firefox ATM) let you read (and write) raw image data from an image object, so it’s conceivable that you could send data down the pipe encoded as images and poll the image client-side for updates, decoding it back to (json encoded?) data. Ridiculous… but I’m tempted to try it.