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 (鵜飼文敏) <[email protected]>wrote: > > > On Wed, Nov 18, 2009 at 6:08 AM, Maciej Stachowiak <[email protected]> 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 > [email protected] > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > >
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
