[webkit-dev] Staging WebSocket protocol deployment

[Maciej Stachowiak]

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>  
> wrote:
>> +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
> webkit-ws).

My impression from the IETF mailing list is as follows:

(a) The IETF is likely to charter a Working Group to work on the  
WebSocket protocol.
(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  
dates.

(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.


Regards,
Maciej


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20091113/c32acabf/attachment.html>