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.
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.
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?
- WBR, Alexey Proskuryakov
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
