3 ms·
Sensible response by Mozilla, but a shame that means we won't be seeing websockets included in the near future.
by joshsharp 16y ago
Sensible response by Mozilla, but a shame that means we won't be seeing websockets included in the near future.
- Rauchg 16y agoI 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.
- robryan 16y agoHaving 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.
- jamii 16y agoI 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.
- mbrubeck 16y ago"There's a very low chance that the developer API will change anyway." If you include server-side developers, then part of the developer API (the protocol) has already changed compared to Chrome's implementation.