[webkit-dev] Staging WebSocket protocol deployment
jorlow at chromium.org
Tue Nov 17 04:25:12 PST 2009
On Mon, Nov 16, 2009 at 5:45 PM, Alexey Proskuryakov <ap at webkit.org> wrote:
> 15.11.2009, в 17:18, Yuzo Fujishima написал:
> Reason 1: It connotes that the feature is experimental. That means there
>> will be less developers seriously use that feature. Without serious use,
>> we'll have less serious feedbacks from the real world. If the Web Socket
>> has serious flaws, we should rather know them sooner than later. I'd say
>> only serious uses can help us find the flaws faster.
> It doesn't seem that wide use is possible before the protocol evolves into
> something that works with all proxies - or before a heavyweight service
> forces network administrators to update their proxies for compatibility with
> the existing protocol. Frankly, I think that the former is more likely.
> The only case that is likely to work on Internet reliably right now is
> running over SSL, which negates some of the protocol's strengths - it will
> no longer be as efficient as it's meant to be. In order to enable port
> sharing, this also requires one to serve documents over https, which is an
> additional cost.
You're right that WebSocket users will need to use SSL to get around proxy
issues, but I don't think it's actually that big of a deal. I know of
several sites looking at using them; all are planning on using SSL, and I'm
not aware of any being particularly concerned about this.
As for the proxy issues themselves: they're not going to go away any time
soon. And the longer we label this protocol as experimental, the longer
it's going to take for things to move forward.
> Reason 2: What should other browser vendors do? Should they use
>> chrome-ws, firefox-ws, ie-ws, opera-ws, ..., etc? I believe at least
>> will not happy with that. If the vendors need to reach the consensus on
>> common experimental name, say prelim-ws, then why not just use ws instead?
> In practice, this means half a dozen lines of browser detection code -
> which does not matter when deploying a technology of this magnitude, as
> already mentioned in this thread.
That's not the matter. The matter is what this signals to people
considering using WebSockets. Each UA having their own
code typically signals that things are non-standard, which is not true in
> It seems that a common argument against using a name other than "ws" is
> that a scheme is just an opaque identifier, so it doesn't matter which name
> to use, so we can just change the name later, if necessary. I don't think
> that this is a strong argument - if the name doesn't matter in the long run
> (which I wouldn't agree with, but anyway), why sweat about what the name is
> during experimental rollout of the feature?
This argument works both for and against.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev