On Mon, Nov 16, 2009 at 5:45 PM, Alexey Proskuryakov <[email protected]> wrote:
> > 15.11.2009, в 17:18, Yuzo Fujishima написал: > > > 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. >> > > > It doesn't seem that wide use is possible before the protocol evolves into > something that works with all proxies - or before a heavyweight service > forces network administrators to update their proxies for compatibility with > the existing protocol. Frankly, I think that the former is more likely. > > The only case that is likely to work on Internet reliably right now is > running over SSL, which negates some of the protocol's strengths - it will > no longer be as efficient as it's meant to be. In order to enable port > sharing, this also requires one to serve documents over https, which is an > additional cost. You're right that WebSocket users will need to use SSL to get around proxy issues, but I don't think it's actually that big of a deal. I know of several sites looking at using them; all are planning on using SSL, and I'm not aware of any being particularly concerned about this. As for the proxy issues themselves: they're not going to go away any time soon. And the longer we label this protocol as experimental, the longer it's going to take for things to move forward. > 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? >> > > In practice, this means half a dozen lines of browser detection code - > which does not matter when deploying a technology of this magnitude, as > already mentioned in this thread. > That's not the matter. The matter is what this signals to people considering using WebSockets. Each UA having their own code typically signals that things are non-standard, which is not true in this case. > It seems that a common argument against using a name other than "ws" is > that a scheme is just an opaque identifier, so it doesn't matter which name > to use, so we can just change the name later, if necessary. I don't think > that this is a strong argument - if the name doesn't matter in the long run > (which I wouldn't agree with, but anyway), why sweat about what the name is > during experimental rollout of the feature? > This argument works both for and against.
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
