Re: [hybi] Proposed way forward for WebSockets

[Willy Tarreau <[e-mail]>]

Hi Ian,

On Tue, Jul 27, 2010 at 12:56:07AM +0000, Ian Hickson wrote:
> 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 globally agree with this plan, but everything depends on what we
consider a critical bug and if a missing feature can be seen as a
bug (eg: keep-alives or pings), since these *will* cause random
hangs on long-lived connections. The protocol should really define
at least a NOP message that must be ignored by either end.

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

I would see it differently : when the spec makes it impossible to add
new features, there is no way we'll see richer implementations demonstrating
the need for those features. Look at HTTP for instance : it is very
extensible and keep-alive would never have existed if it had not been
permitted by the protocol spec.

Last, there is something I find complicated when reading the spec : it is
defined exactly as code. When you read it, you read code written in english.
It is very hard to implement something correct based on this because you
don't easily know what relates to *your* implementation, nor how your
implementation specific issues should be handled.

Having an additional section which defines the protocol instead of how to
process it would tremendously help.

Regards,
Willy