Re: [hybi] Proposed way forward for WebSockets

[Jamie Lokier <[e-mail]>]

On 27/07/2010, at 10:56 AM, Ian Hickson wrote:
> Here's a proposed timeline for adding these features:

Hurrah! I'm in broad agreement with this proposal.

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

[stuff]

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

Critical issue:

After the first deployment wave, how can client WebSocket
implementations request features without breaking the existing
services that *reject* and *close* connections with additional state
in the headers?

The subprotocol field (as is) cannot be used for this by a WebSocket
API implementation because it is not allowed to change what the script
provides.

Imho a robust, extensible negotiation slot must be present early for
this plan to work.  Assuming this is agreeable as a requirement we can
work on making it simple, robust, and secure.

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

I wholeheartedly support the notion that scripts could implement
protocol features that the browser doesn't perform natively - where
possible.

I'd like to remove one of your asterisks:

Useful connection sharing *cannot* be implemented in script:

- How do you share a connection among multiple tabs?
- How do you report the message events back to each tab?
- How do you avoid blocking all tabs communications when a single tab
  has a full event queue and is too busy to empty it?

Browser security makes it somewhere between very difficult and
impossible, depending on what browser quirks you take advantage of.
This is already a problem today, using long-get HTTP.

Connection sharing in a single tab is of course possible, but
that also has limitations.

It is conceivable to script a replacement WebSocket object type which
"emulates" it on top of the real one while sharing conenctions in a
single tab.  It would be good to determine if that's practicable.  I
imagine it'll behave too different from the real one to be a drop-in
replacement because of browser script limitations.

Negotiation faces the same problem as described earlier for the
WebSocket API implementation itself - namely that the subprotocol
field can't be used.

The solution is the same as earlier - with the addition that scripts
need to be able to participate in negotation by requesting features
(and somehow getting involved at the frame type level?) - which means
an additional API function.

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

I'm not sure what makes compression clearly needed.  This is not an
argument against, just that I seem to be missing something.

I agree that piecemeal features is good idea, and I support that
approach.  The framework does need to be flexible enough to accomodate
piecemeal features for it to work out.  At the moment the handshake
may be too rigid and prevent it working out.

Although I think it's a good plan, don't assume piecemeal features
automatically results in better client-side compliance.  It makes it
simpler to write throwaway implementations.  That is useful, but might
also result in *less* compliance on average with the base protocol due
to quick and dirty implementations being good enough.  We'll see.

I'm not sure what HTTP history has to say about *client*-side
implementations in this regard.  Regarding HTTP servers, history shows
us that the first decade was littered with buggy, non-compliant
servers due to the ease of writing bad but good enough ones.
Compliance increased dramatically since sophisticated fully-featured
servers became more popular.

-- Jamie