I disagree. The argument is that it's under constant change and discussion. This is true for every single part of the development stack. It's important to just get it out there and iterate in response to what developers are _doing_ with WebSocket. The sample size to justify Content-Encoding: gzip, deflate in that mailing list post is two, and is very unlikely to grow if Firefox doesn't add support! We could discuss theoretical improvements to WebSocket for months on a mailing list.
If you look at the initial discussions about the WebSocket protocol, much was said about reconnection negotiation, queues/batches support, meta headers, et cetera. Discussing a feature forever holds back progress. Firefox argues that there's "a lot of ongoing discussion", but that's been the case since Day 1.
Firefox should do what Chrome 4 did, add it, then continue to improve it. There's a very low chance that the developer API will change anyway.
I like the chrome approach of including experimental features in stable builds but requiring a command line switch to turn them on. It makes it much easier to try out new features without making people expect future compatibility.
Having it in firefox and chrome would encourage a lot more development around it. As it stands I don't think people would want to invest to much past experimentation in taking advantage of a feature that is only present in chrome.
This is one reason I'm not particularly fond of Mozilla. They care too much about ideology, PR and all that stuff. They have had the code but won't release it because it could make them look bad or annoy some web devs or doesn't fit their ideology. Why can't they just release stuff and see how it fares, and improve it based on public's response.
It's not just about ideology and PR... it's about keeping our users secure.
And the "ideology" has a very pragmatic side: it's about keeping the web based on actual standards that can evolve rather than defacto standards that we will have to live with forever.
We're dealing with this on the Mozilla Mobile team because of touch events. There is no standard for touch events in browsers. Mobile Safari and Android both implement touch events, and their implementations are partly compatible and partly incompatible. Mobile Firefox could choose to take one of those implementations and copy it. In the short term it would make us more compatible with some existing iPhone-optimized sites. But in the long run it would raise the barrier for getting web sites (and browser vendors) to switch to an actual standardized API. So we're going to try to get the WHATWG to agree on a standard for touch events before we implement them rather than after. The standards process is not just about ideology - it often catches significant design and security flaws, as it has with WebSockets.
It's much harder to change an API once you've shipped it to a userbase like Mozilla's (hundreds of millions of people - around 30% of all internet users). Remember the story about Stuart Feldman when he was asked to make the Makefile syntax more sensible? He said he couldn't, because there were already over a dozen people using it.
KDE, an ideological group? Really? I've found KDE people to be very pragmatic, not ideological. KDE's history and their choice of Qt also supports that, remember that FSF (there's an ideological group for ya) rejected KDE for some time, and creted Gnome to compete with it purely for ideological reasons. KDE in comparison was created because the founder felt the need for a good desktop environment for unixy systems.
