Re: [hybi] Proposed way forward for WebSockets

[Maciej Stachowiak <[e-mail]>]

Ian's suggested timeline below sounds like an excellent way to proceed, in my opinion.

 - Maciej

On Jul 26, 2010, at 5:56 PM, Ian Hickson wrote:

> On Mon, 26 Jul 2010, James Graham wrote:
>> 
>> I think a different goal would be a better statement of Ian's intent:
>> 
>> "Websockets should be the minimal layer on top of TCP needed to meet the 
>> additional requirements of browsers"
> 
> Yes, I think that's an accurate description of what I mean.
> 
> 
> There are two parts to the protocol: the handshake, and the framing.
> 
> The handshake has basically three purposes: 1: allowing the protocol to be 
> served by a server that also serves HTTP on the same port; 2: protecting 
> existing servers and future WebSocket servers from cross-protocol attacks; 
> 3: allowing servers to host multiple domains and resources on the same 
> IP/port combination, while supporting the browser origin security model.
> 
> The framing has one purpose: provide JavaScript applications running in 
> Web browsers with a way to send and receive text messages to and from 
> WebSocket servers.
> 
> 
> There are a number of ways that we can make the protocol also support 
> other goals:
> 
> - Compression of frame data
> - Sending and receiving binary data
> - Allowing messages to be annotated with metadata*
> - Allowing multiple JavaScript applications from the same browser to 
>   share a connection to a server (multiplexing)*
> 
> All of these could be supported by future backwards-compatible changes to 
> the protocol, by having the client advertise support for each feature in 
> the handshake, and having the server opt-in to using that feature. None of 
> these changes require fundamental changes to the handshake.
> 
> Two of these, marked with an asterisk above, can also be implemented by 
> script; therefore a good way of determining if they are truly needed is to 
> deploy the protocol as is, and to see if people work around the lack of 
> that feature by implementing it themselves. If they do, then the feature 
> is needed and we should add it.
> 
> The other two features are clearly needed regardless, and we should add 
> them in the near future. (Adding features piecemeal leads to more 
> compliant client-side implementations, so we should not add them now.)
> 
> 
> Here's a proposed timeline for adding these features:
> 
> - We fix any critical bugs (not feature additions) in the protocol as it 
>   stands today (next 4 weeks).
> 
> - We deploy the protocol in four or more major browser vendors (next 4
>   months).
> 
> - When binary support in WebGL is stable, we add binary support to XHR, 
>   WebSocket, etc (a matter of months?).
> 
> - We look at how the protocol is used (another couple of months).
> 
> - During this time, we build client and server test suites for the 
>   protocol.
> 
> - We add built-in support for the features that are needed based on 
>   implementation experience (about 6 months from now), including 
>   compression, multiplexing, per-frame metadata annotation, etc, as 
>   needed.
> 
> - We update the test suites.
> 
> 
> I think it would be a mistake to add every feature we can think of right 
> away, because doing so would mean that we added features before their need 
> was proven, and it would lead to much less conforming client 
> implementations. This dynamic has been proven time and time again with Web 
> technologies; we should not repeat that mistake.
> 
> It would also be advantageous to allow implementors to experiment with 
> ideas like multiplexing before we add the feature to the protocol, since 
> it would let us use their implementation experience when designing the 
> extensions to the protocol. Only by first getting the basic protocol out 
> there and then experimenting with it can we really find how these ideas 
> work out in real deployments.
> 
> 
> (Thanks to Ian Fette for providing a sounding board for some of this.)
> 
> -- 
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
> _______________________________________________
> hybi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi