[webkit-dev] Staging WebSocket protocol deployment
Maciej Stachowiak
mjs at apple.com
Tue Nov 17 13:08:40 PST 2009
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
More information about the webkit-dev
mailing list