websockets – shipping before it’s ready?

Anne from Opera has posted about their support for WebSockets in Opera 10.70. Unfortunately, they will be shipping -76, which is a version of the protocol that will be replaced. And it’s in the official namespace, which means that if you’re going to use WebSockets, you’re also going to have to do UA detection to know which version of the protocol the browser supports. This isn’t good.

Our current plan in Firefox is to ship -76, but with a private namespace. Why? Because we know the protocol is going to change so it’s important for developers to be able to tell which version of the protocol a browser actually supports. We’re leaving it in just for testing. WebSockets should not be considered production yet.

I can’t speak for the Chrome team because I don’t work for Google, but my understanding from talking with the people there is that they will change the protocol in Chrome once a new version of the protocol is out and push it out in one of their releases. (The current editor of the spec, Ian Fette, works on the Chrome team at Google.)

Anne, displaying some unintentional self-parody, says It will be interesting to see if we ever do get rid of -76.. Note that the best way to end up getting stuck with something is shipping it before it’s ready. Just saying.

I’ll be pretty disappointed if we end up with a world in which one browser shipped earlier than it should, it gets added to HTML5 scoring web sites and then it ends up in every other browser for product marketing reasons. And by effect we end up with something that isn’t very good because we were in a hurry.

It’s a protocol. We should spend some time getting it right.

That being said, there has been quite a bit of progress in the working group and many open issues have been settled. The draft somewhat lags behind consensus, but I would expect updates soon.

This entry was posted in Web Standards, WebSockets. Bookmark the permalink.

18 Responses to websockets – shipping before it’s ready?

  1. F1LT3R says:

    Good call sir!

  2. Pingback: websockets | 9nd.pl

  3. sircall says:

    Good call? No, bad call!

    You do realize that this is an Opera snapshot? A pre-alpha version, basically? Experimental?

    Nothing is “shipping.” It’s experimental. A preview. It isn’t even available as a beta from http://www.opera.com.

  4. FUDFAIL says:

    “We’re leaving it in just for testing”

    Much like Opera in their pre-alpha snapshots, then?

    Mozilla, FUD, fail.

  5. Anne says:

    As a browser with not a whole lot of market share we do not have much choice in the matter. Furthermore, what is currently shipping in Firefox 4 betas (similar to our 10.70 nightlies) is not prefixed either, and last I checked there is not consensus yet on Mozilla’s position either. At least not in the bug about prefixing WebSocket usage.

    Once Chrome, Firefox, et al start prefixing it should not really matter what we do.

  6. Peter says:

    Wait, what? Chrome does it, Firefox 4 does it and now you criticize Opera for doing it? Makes little sense.

  7. Julian Reschke says:

    Quoting Anne v. K. on IRC:

    # [10:40] well unless something changes our final will ship unprefixed too (http://krijnhoetmer.nl/irc-logs/whatwg/20101012#l-331)

    …self-fulfilling prophecy?

    Anyway, all browser vendors are present in the IETF HyBi Working Group, so I think the best way to move forward is to actually discuss the problem where it belongs and agree upon a plan with respect to marking the support as experimental, possibly prefixing the API and/or using a temporary URI scheme.

  8. F1LT3R says:

    @Julian Reschke: just wondering about the phrase “possibly prefixing the API”, are you suggesting there is a reason not to prefix the API?

  9. Julian Reschke says:

    @F1LT3R: it has been pointed out that the API is stable (no opinion on this), while the protocol is not (which definitively is the case). In that case, it would make sense to leave the API alone, and version the URI scheme instead.

  10. rob says:

    @Julian Reschke

    You left out this followup comment from Anne:

    # [10:41] if Chrome et al were shipping with a prefixed version of some kind, so would we
    (http://krijnhoetmer.nl/irc-logs/whatwg/20101012#l-334)

    How come?

  11. Julian Reschke says:

    @rob I don’t think it’s productive for *any* of the browser vendors to do this kind of finger pointing. Decide on what’s the right thing to do, and then do it, no matter how big your market share is.

    It’s not like Microsoft is shipping this already, so there is time to get things right. But that requires that those who decide actually *want* to get it right.

    Right now my impression is that at least some prefer to play the “we told you so” game, being unhappy with the fact that responsibility for the protocol moved into an IETF Working Group.

    So, again, the vendors should solve the problem in the Working Group; that’s what it is for.

  12. @FILT3R: the API isn’t an IETF work/deliverable, only the protocol is; and the API is quite stable. If something has to be “prefixed,” it’s the “procotol,” not the API.

    FYI, there’s been a proposal on the IETF HyBi WG to send the I-D version on the wire so that the actual protocol used could be “negotiated.”

  13. Actually you can do object detection…

    ——————-
    if (document.getElementById(‘body’).style.OObjectFit!=undefined && navigator.geolocation) {browser=’Opera’; browser_version=’10.7+’;}
    else if (document.getElementById(‘body’).style.OTransform!=undefined && navigator.geolocation) {browser=’Opera’; browser_version=’10.6′;}
    ——————-

    I personally do like seeing features come to a browser to mess around with though if the specification is not finished it really should have a prefix which saves the headache of object detection.

    Opera has some CSS 2.1 bugs that still afflict my site even to this day and some people at Mozilla keep wasting time merging extensions in to the browser directly. No browser is perfect and I don’t agree with all the decisions made by any browser and I do find many features and error handling to be useful across the big four rendering engines.

    I can’t wait for the resize property to become more prevalent as this textarea is devastatingly small.

  14. grahame says:

    There’s a pretty huge opportunity cost to having a protocol like this stuck in a committee for an extended period. Maybe Opera releasing it a bit early will hurry things up getting the final version sorted.

  15. F1LT3R says:

    @Julian Reschke, Thomas Broyer: OK, I follow what you’re saying now. :) ….With regards to “I don’t think it’s productive for *any* of the browser vendors to do this kind of finger pointing.” Julian, the way I understood it (correct me if I’m wrong), finger-pointing generally lights fires in the right places?

  16. rob says:

    But @Julian Reschke, no one is doing any finger pointing here, apart from Mozilla. Anne just pointed out that Mozilla is doing what they criticized Opera of doing. You also seemed to point fingers at Anne by taking a quote out of context.

  17. We have a bug open to move to a prefixed namespace before Firefox 4 RC:

    https://bugzilla.mozilla.org/show_bug.cgi?id=602028

    Sorry for the confusion around that.

    That being said, saying that the API isn’t changing so it’s OK to keep the namespace while the underlying protocol is changing doesn’t make much sense to me.

  18. Ivo Wetzel says:

    It’s not the vendors fault. It’s the spec which is missing a freaking version field(!). One should know by now that on the web, things get adopted way before they’re finalized.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre lang="" line="" escaped="">