Re: [hybi] Is there a traffic jam?

[Greg Wilkins <[e-mail]>]

Ian Hickson wrote:
> I'm happy to add more complexity (so long as it is justified) to the 
> client implementation, with the caveat that it must not also increase the 
> complexity of the server-side implementations.

Would it be sufficient to allow optional support of complex features.
So a server could implement a either a simple core of websocket or
a richer more complex feature set?

Also, you have argued against additional frame-type that could better
support complex behaviour on the grounds that the base frame types
can carry that complex protocol with assumptions.   If a mime-encapsulating
frame type is not worth a dedicated frame-type byte, then what
kinds of extensions do you see additional frame-type being defined for?




> The client component has to deal with any server, including non-conforming 
> servers sending back garbage, future servers that support an extended 
> version of the protocol, etc.

Welcome to the wonderful world of web protocols!

> Server components only have to deal with the 
> output possible from their own scripts driving a conforming implementation 
> of the API. We can leverage that asymmetry.

I do not think this is generally true.

Server that will implement the websocket protocol are more than likely
going to be done by entirely different sets of developers than those
that write the javascript content that is served from them.

More over, the javascript served will probably be from 2, 3 or even
more distinct sets of developers as frameworks, mashups and other
such things will bring together the work of many into a single page.

There is also the likely hood of more and more cross-site support
and websockets will have to support cross site in some way, so a server
may receive connections from code it didn't actually serve.

Furthermore, intermediary proxy's etc. may alter what is sent/received.
Even if the initial proxies/firewalls don't,  I'm sure somebody will
develop some smart websocket aware proxy that does some

So Server components also have to deal wit non-conforming clients
sending back garbage etc. etc.


> This is why currently the spec for the client side defines the entire 
> protocol (including binary frames which might be sent by servers in the 
> future), but the spec for the server side only defines the rules required 
> for handling content sent by the current client API.

I think the specification should entirely define the wire protocol without
any assumptions about who/what/where is implementing the client or the
server.    If we wait for non-js-in-browser clients before fully specifying
the server side of the protocol, then we have a chicken and the egg problem.


cheers