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.

WebSync On-Demand is back online again. The total outage time was approximately one hour.

At the moment, we believe the outage was caused by a misconfiguration of our load balancers by datacenter personnel. We are attempting to determine how this happened to prevent it in the future.

For those who are interested, for the past 12 months, we've had 6 hours of total downtime, giving us a 99.93% uptime.

Hey folks, we're having a small issue with our server cluster at the moment, and we're working with our data center to resolve the problem. We'll update here as soon as we have things resolved.

[Edit, 12:05EST] The servers are all back up again. Apologies for the inconvenience.

Happy New Year! A new release of WebSync is out! This is basically a patch release, fixing a bunch of minor issues in the 3.3 branch.

Feel free to check out the changelog, download a new trial, update your purchase, or use the latest On-Demand code by pointing your script tag to ?v=3.3.2.

Happy Coding!