[webkit-dev] Staging WebSocket protocol deployment

[Jeremy Orlow]

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
>> developers
>> will not happy with that. If the vendors need to reach the consensus on
>> the
>> 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
this case.


> 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...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091117/a69bdebc/attachment.html>