Re: [hybi] Proposed way forward for WebSockets

[Michael Carter <[e-mail]>]

Ian's roadmap looks great, in my opinion.

-Michael Carter

On Mon, Jul 26, 2010 at 5:56 PM, Ian Hickson <[e-mail]> 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
>