WebSync and WebSockets and Comet, Oh My!

WebSync + Websockets

Fairly regularly, we get the question "what is your plan for WebSync and Websockets"? First, let me clarify - Websockets is a transport over which WebSync will operate, one of many we already support depending on your particular browser and environment. We already support long-polling via xhr, iframe, jsonp...and this will be another mechanism under the hood. However we end up implementing Websockets, WebSync's main API will remain the same - you'll still connect, subscribe, publish, etc.; it'll just take place over a single Websocket connection instead of multiple HTTP requests.

That said, rest assured that we plan to support Websockets in the future. Whether through IIS natively or a custom module remains to be seen (based mostly on whether Microsoft moves forward with an implementation of Websockets for IIS). To our developers, it should be relatively seamless. If Websockets are available, they'll be used; if not, they won't. Simple as that.

A Spec in Turmoil

We're actively monitoring the development of the spec (we are on the IETF group), but we haven't yet taken the steps to implement it. Why not, you ask? Well...

1. The spec itself is in tremendous turmoil. The various revisions are vastly different from one another, and each browser vendor has implemented a different revision (if they've implemented anything). The group working on the spec (we are in the group, so we count ourselves in this) is taking forever to finalize anything, for both good (lots of valid questions and concerns around security and compatibility) and bad (too much infighting) reasons.
2. Browser support is poor. Safari and Chrome have implementations, but each implements a different version of the spec. Safari is broken - see the next point. Firefox 4 is going to ship with Websockets disabled. IE doesn't support it at all.
3. What *has* been implemented isn't always correct, even for a given vendor. For example, Safari isn't sending the random 8-byte header it should be sending according to the version of the spec it implements, so we couldn't implement it there even if we wanted to.
4. Server support is limited. This point isn't a deal-breaker, but since WebSync already plays so nicely with IIS, it would be nice to see Websockets support come from Microsoft. If MS doesn't step up here, we plan on running with it anyway.

So, at the moment, we're playing the waiting game, and we look forward eagerly to the day when all browsers properly implement a stable version of the protocol.

Comet Lives On!

Another question we often get is "is WebSockets the death of 'comet'", to which I respond with an emphatic "no", for a number of reasons:

1. Old browsers will always be around. People are still using IE6, now 10 years old. Websockets isn't even a final draft form yet, so we'll have 10 years more of supporting older browsers at *least* before Websockets takes over 100%.
2. "Comet" is a concept. Websockets will be included in WebSync when it's out of draft, but WebSync will still be a comet server. The "death of comet" doesn't make sense. Yes, Websockets will mean we can use a better transport for streaming data, but the fallbacks will still be needed to deal with old browsers (see above) and also to handle proxies that don't support Websockets properly.
3. Server implementation is still necessary. Most of the difficulty in implementing a comet server is dealing with the web server and database concurrency, which doesn't change if the client-side implementation changes. You'll still need a way to easily publish and distribute messages to a large number of connections; the only difference is that the connection sticks around for communication in both directions, and new HTTP headers aren't sent.

We can't wait for Websockets to be generally available, but we're also well aware of the fact that it won't negate the need for existing client-side solutions for a long time, nor will it suddenly remove the need for efficient server-side code to manage all those clients.