Re: [hybi] Multiple connections serialization and proxies

[Ian Hickson <[e-mail]>]

On Tue, 20 Jul 2010, John Tamplin wrote:
> On Tue, Jul 20, 2010 at 7:14 PM, Ian Hickson <[e-mail]> wrote:
> > > 
> > > I favour the server being able to send back a number saying how many 
> > > more connections are permitted now.  Negotiated flow control, rather 
> > > than spec'd fixed values (except the first).  There could still be a 
> > > default, for simple implementations.
> >
> > That seems like something we should add in a future version, if it 
> > really is needed. Baby steps, keep things simple, etc.
> 
> Given the lack of extensibility and negotiation, how would it be added 
> in the future without breaking backwards compatibility?

There's no lack of extensibility and negotiation, both are built into the 
protocol. Future versions of the protocol can simply define new option 
fields that the client can include to announce support and that the server 
can include to announce opt-in. For example, the client could say:

   Sec-WebSocket-Compression: gzip bzip2

...and the server might then respond with:

   Sec-WebSocket-Compression: gzip

...indicating that the client and server will both compress frames using 
gzip. Pretty much anything can be defined; if both the client and the 
server opt in to a feature, nothing constrains what the protocol has to 
look like from then on. We could define an option that, once selected by 
both parties, switches the protocol to an entirely different framing 
mechanism, if we find that the simple framing currently in the spec isn't 
good enough. So long as we define all the interactions of the options, 
we're pretty much open to doing anything in future versions short of 
changing the basic shape of the handshake.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'