There are also Flash shims available on the client side, so you can use a WebSocket API that falls back to Flash on legacy browsers: http://github.com/gimite/web-socket-js
So what you're saying is that first there's a period of "proprietary extension" which we should shun because that's evil incarnate, then one day someone flips a switch and it becomes a standard and we mock the people left behind. [I don't meant that's actually what you write. A more figurative "you" with a generous interpretation of "anyone promoting HTML5 today].
For many years now, the rallying cry of the web has been "industry standards". But now, suddenly, we have redefined standard to be something like "Google said so". Sometimes Apple gets to say so.
Without apologizing for how bad IE may have been, I am uncomfortable with this turn of events for two reasons:
1. It smells like hypocrisy. A lot.
2. HTML5 isn't slated to actually be a standard until 2012. Basically requiring implementations to work to a proto-spec kind of defeats the purpose of having standards.
Let's say, just theoretically, that IE implements web sockets according to the draft. Then a day later, the Google employee who writes the draft changes it. How many hours until there's a HN post about how IE implements web sockets wrong?
I think there's a big difference between implementers working in the open to write standards and create test implementations and keep the public informed about the progress toward standardization - as Mozilla, Apple, Opera, and Microsoft are doing with HTML5 and related efforts - as opposed to developing in secret, and launching new features fully-formed into the wild with no chance for discussion and usually no adequate spec, as both Microsoft and Netscape did during the browser wars.
Agreed. Except for the part where nobody seems to consider these "test" implementations. I'm not so much critical of the process as the apparent developer community attitude/reaction/expectations to a work in progress.
Most of the reactions I see here and on Reddit are dozens of people saying, "Great, I can't use this until it's in IE." I'm not exactly seeing mainstream sites depending on these in-development technologies.
Not quite right. Nothing will be in HTML5 as a final recommendation unless it's in 2+ major implementations. There's plenty in the current drafts of HTML5 which has not yet been implemented.
Ok, I've never worked with Orbited. But I looked at the site, through the examples, and through the documentation, and I see nothing about being able to use WebSockets on, say, IE7 or Safari.
Orbited looks like an event-driven webserver, which is nice and all, but it doesn't magically give WebSocket functionality to legacy browsers.
Orbited functions as a proxy which lets you use a raw socket on your server end to communicate through the black-box Orbited in the middle to a JavaScript API that looks roughly like the WebSocket API. So as far as you as a developer are concerned, the code you have to write is about the same as if you were using WebSocket directly.
As far as I remember, BOSH is just built on long polling, and uses an XML-based syntax to define its protocol. The general idea is the same. The main differences: (0) perhaps most importantly it’s not immediately obvious how to send messages that aren’t XML-based over BOSH, because the protocol is defined in terms of XML payloads, meaning that if you have some protocol that wants to send arbitrary messages you’ll have to do something like putting your messages inside a CDATA block or escaping special characters, and your server-side code will need to come up with some way to do that, (1) Orbited’s design is a bit more general, accommodating transports other than long-polling, (2) Orbited has a bit less overhead, even in long polling mode, because it doesn't include a bunch of extra XML, (3) everything on the client end related to the particularities of Comet communication is designed to be treated as a black box by client-side JavaScript, which can just load Orbited’s JavaScript and then deal with its API – your in-browser code can roughly pretend it has a TCP socket, (4) Orbited operates as a proxy, speaking actual TCP out the back end, which means that your server code can just be written against a TCP socket and doesn’t need to implement anything special to communicate with browsers, or import any libraries, etc.
