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 &quot;standardize&quot; on the x or use our own prefixes.<div><br></div><div>If we go with option 3, I think a WebKit blog post would be a good way to make out intentions for WebSockets clear.<br>

<div><br><div class="gmail_quote">On Wed, Nov 18, 2009 at 4:38 AM, Fumitoshi Ukai (鵜飼文敏) <span dir="ltr">&lt;<a href="mailto:ukai@chromium.org">ukai@chromium.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br><br><div class="gmail_quote"><div class="im">On Wed, Nov 18, 2009 at 6:08 AM, Maciej Stachowiak <span dir="ltr">&lt;<a href="mailto:mjs@apple.com" target="_blank">mjs@apple.com</a>&gt;</span> wrote:<br></div><div class="im">

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div><br>
On Nov 15, 2009, at 5:18 PM, Yuzo Fujishima wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
I&#39;m against prefixing with &quot;webkit-&quot; because of the following reasons.<br>
<br>
Reason 1: It connotes that the feature is experimental. That means there<br>
will be less developers seriously use that feature. Without serious use,<br>
we&#39;ll have less serious feedbacks from the real world. If the Web Socket<br>
has serious flaws, we should rather know them sooner than later. I&#39;d say<br>
only serious uses can help us find the flaws faster.<br>
</blockquote>
<br></div>
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&#39;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&#39;d personally like to see some more experimental implementations before we lose the ability to make incompatible changes. See below for some specific suggestions.<div>



<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Reason 2: What should other browser vendors do? Should they use<br>
chrome-ws, firefox-ws, ie-ws, opera-ws, ..., etc? I believe at least developers<br>
will not happy with that. If the vendors need to reach the consensus on the<br>
common experimental name, say prelim-ws, then why not just use ws instead?<br>
</blockquote>
<br></div>
Historically, we haven&#39;t had a problem with WebKit-prefixed features - it seems that other browser vendors implement under their own prefix and content adapts to deal.<br>
<br>
Anyway, getting back to the suggestions... I think it&#39;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.<br>




<br>
Here is an extended list of ideas (ones that I think are practically doable):<br>
<br>
1) Change the URI schemes to &quot;webkit-ws&quot; and &quot;webkit-wss&quot; - the vendor prefix strategy.<br>
2) Change the URI schemes to &quot;x-ws&quot; and &quot;x-wss&quot; - a vendor-independent experimental prefix.<br>
3) Don&#39;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.<br>




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




5) Make the feature runtime switchable (using some semi-hidden UI) and off by default.<br>
<br>
I&#39;d like to hear opinions on which of these is best.<br></blockquote><div><br></div></div><div><span>I vote option (3).</span></div>

<div><br></div><div>Even if we keep current protocol stack with prefixed URI,  I&#39;m wondering any websocket server implementation will keep compatibility with procotol of our prefixed URI..</div><div>Or, if some websocket server implementation keeps compatible with prefixed URI, I believe it&#39;s worse situation for future.</div>



<div> -- </div><div>ukai</div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I&#39;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?<br>
<br>
Regards,<br><font color="#888888">
Maciej<br>
<br>
</font></blockquote></div></div><br>
<br>_______________________________________________<br>
webkit-dev mailing list<br>
<a href="mailto:webkit-dev@lists.webkit.org">webkit-dev@lists.webkit.org</a><br>
<a href="http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev" target="_blank">http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev</a><br>
<br></blockquote></div><br></div></div>