[webkit-dev] Staging WebSocket protocol deployment
mjs at apple.com
Fri Nov 13 17:00:10 PST 2009
On Nov 13, 2009, at 4:06 PM, Adam Barth wrote:
> On Fri, Nov 13, 2009 at 3:58 PM, Jeremy Orlow <jorlow at chromium.org>
>> +1 for AP's plan.
> There's nothing magical about ws and wss. We can change those names
> later if we change the protocol (just as easily as we can change
My impression from the IETF mailing list is as follows:
(a) The IETF is likely to charter a Working Group to work on the
(b) It will specifically be more or less based on the WebSocket
protocol as specified today.
(c) There is a lack of consensus about some details (such as whether
the baseline should support multiplexing, whether messages should
always be length-prefixed and not sentinel-terminated, etc).
I don't want to give the likely future IETF WG participants the
impression that we're trying to lock in the protocol and pre-empt
decisions on potential issues of controversy. I think we (the WebKit
community) would really like the WebSocket protocol to succeed, but I
don't think we care about some of the fine details enough to try to
lock them down or pick a fight with the IETF. I will also add that
there are times when rushing to ship features has turned out to be
somewhat regrettable in the past.
Thus I suggested that we should look into ways to avoid prematurely
locking in the protocol. In particular, if the standard changes
incompatibly relative to what we ship but there are already sites
using the current protocol, I'd like it to be possible for WebKit to
support both new-style and old-style sites. Here are some options:
(1) For now, ship with webkit-prefixed versions of the URL schemes (if
the protocol changes incompatibly, we can make the standard ones use
something different; if it doesn't, we can just make it an alias.)
This is basically Alexey's proposal.
(2) Use the same URL scheme, but rely on some provision for versioning
in the WebSocket protocol itself. I don't think there is anything
suitable currently. In particular we would need to be able to
negotiate the protocol version to use with the site, so both v1 and v2
sites would work. And I don't think there's time to add version
negotiation to the spec and implement it before various vendor ship
(3) Use ws: or wss: for now, but plan to change the URL scheme in the
standard if the protocol does change incompatibly. This assumes buy-in
from the specifiers of the protocol
I like (1) best, because it's totally future-proof and not
presumptuous. I think Ian and Adam Barth are effectively suggesting
(3), but I feel like it sends a bad message to assume the eventual
IETF Working Group will work around our compatibility needs. Worse
yet, they may choose not to do so. Either way, I'd like us to have a
plan where we can show we are not trying to pre-empt decisions about
the details of the protocol.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev