[webkit-dev] Staging WebSocket protocol deployment

[Yuzo Fujishima]

Hi, Maciej,

I vote for (3).

Yuzo

On Wed, Nov 18, 2009 at 6:08 AM, Maciej Stachowiak <mjs at apple.com> wrote:

> On Nov 15, 2009, at 5:18 PM, Yuzo Fujishima wrote:

>> Hi,

>> I'm against prefixing with "webkit-" because of the following reasons.

>> 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.

> I think this captures the root of the disagreement. Personally, I would
> like
> to do something to send the message that WebSocket is still somewhat
> experimental. It's true that the spec has been in development for a long
> time. But we are only now seeing the first client-side and server-side
> implementations. A number of issues were discovered in that process, and
> I'd
> personally like to see some more experimental implementations before we
> lose
> the ability to make incompatible changes. See below for some specific
> suggestions.


>> 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?

> Historically, we haven't had a problem with WebKit-prefixed features - it
> seems that other browser vendors implement under their own prefix and
> content adapts to deal.

> Anyway, getting back to the suggestions... I think it's reasonable at this
> point to indicate that the WebSocket protocol is somewhat experimental
> (probably more so than the API). I will recommend doing something along
> those lines for the next release of Safari. If we can get rough consensus
> within the WebKit community that we should label the protocol
> experimental,
> and how we should do so, then we can just make the change in WebKit and
> vendor releases will follow along.

> Here is an extended list of ideas (ones that I think are practically
> doable):

> 1) Change the URI schemes to "webkit-ws" and "webkit-wss" - the vendor
> prefix strategy.
> 2) Change the URI schemes to "x-ws" and "x-wss" - a vendor-independent
> experimental prefix.
> 3) Don't change the URI schemes at all, but communicate in some public way
> that the protocol is not completely locked down yet, and we are largely
> looking for early adopter feedback. We could do this in the form of a
> WebKit
> blog post, for example. And we could reinforce that in developer
> documentation for WebKit-based products.
> 4) Support both unprefixed and prefixed URI schemes, and in addition
> publicize that we will maintain compatibility for the prefixed URI scheme
> but the unprefixed version may have to change (combo of 3 and either 1 or
> 2).
> 5) Make the feature runtime switchable (using some semi-hidden UI) and off
> by default.

> I'd like to hear opinions on which of these is best.

> I'd also like to hear if anyone feels that we should send the message that
> the WebSocket Protocol is production quality and we promise full
> compatibility going forward. Does anyone truly feel this way?

> Regards,
> Maciej