[webkit-dev] Staging WebSocket protocol deployment
jorlow at chromium.org
Wed Nov 18 02:37:51 PST 2009
I think 3 sounds best. 4 seems reasonable. If we need to go with 1 or 2,
we should talk to Mozilla to decide whether to "standardize" on the x or use
our own prefixes.
If we go with option 3, I think a WebKit blog post would be a good way to
make out intentions for WebSockets clear.
On Wed, Nov 18, 2009 at 4:38 AM, Fumitoshi Ukai (鵜飼文敏) <ukai at chromium.org>wrote:
> 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:
>>> 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
>>> 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
>> 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
>> 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
>> 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 vote option (3).
> Even if we keep current protocol stack with prefixed URI, I'm wondering
> any websocket server implementation will keep compatibility with procotol of
> our prefixed URI..
> Or, if some websocket server implementation keeps compatible with prefixed
> URI, I believe it's worse situation for future.
>> 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?
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev