[webkit-dev] Staging WebSocket protocol deployment

[Jeremy Orlow]

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:
>>
>>  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 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.
>  --
> ukai
>
>>
>> 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
>>
>>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091118/08a7da76/attachment-0001.html>