Re: [hybi] How to define the WebSocket protocol (Was: Is there a traffic jam?)

[Ian Hickson <[e-mail]>]

On Fri, 5 Jun 2009, Greg Wilkins wrote:
> >>
> >> 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?
> > 
> > I've mentioned some before; streaming video and JSON data are two 
> > possible examples. Basically anything that requires API-level changes.
> 
> Why doesn't Mime encapsulated data fit that definition? It would require 
> API changes so that meta data associated with the data could be sent and 
> received?

Because, unlike with, say, video streaming, there's really no need to have 
the browsers support this natively -- it can be layered on top of the 
existing API. One of the core principles I've been following in developing 
HTML5 and other APIs for the Web application platform is to make the core 
platform be as light as possible, supporting just the basics, and then let 
library authors layer on top of this what they need.


> >> 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.
> > 
> > In the more advanced cases, maybe. The more advanced the case, the 
> > more professional the programmers involved, the less the complexity 
> > matters. We have to take into account the non-professional case too, 
> > though.
>
> So why not support optionally richer (but more complex) features that 
> better support these mashups, but are well within the capabilities of 
> these superior programmers?

Because in practice there's no such thing as optional features on the Web. 
We'd end up forcing these features on everyone.


> However, I fundamentally reject the premise that a protocol design 
> should be affected by the quality of programmer who may code it.  What 
> other equivalent protocol (HTTP, FTP, SS7, TCP, etc) has been deliberate 
> made less capable so that amateur programmers may be able to attempt 
> implementations?

I don't think the Internet so far have been particularly successful in 
terms of being used by amateurs. HTML and its APIs is an example of a 
language that _has_ been delibrerately made accessible to amateur 
programmers, with an insane level of success. WebSocket is much more like 
HTML than TCP in this sense.


> I have made several clear proposals, which I do feel have been rejected 
> with little attempt to understand the use-cases that motivate them.

I'm sorry you don't feel that I've made an attempt to understand them; I 
thought I had.


> >> 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.
> > 
> > How so? Could you elaborate on this?
> 
> Because if the protocol does not support non-js-in-browser clients, then 
> they will not be implemented because the the protocol does not support 
> them.  Thus if we wait for them to be implemented before defining the 
> protocol to support them, we will wait forever.

I don't understand why the server side of this protocol is affected by 
whether we get non-JS-in-browser clients.

In any case, as far as I can tell the server side of the protocol _is_ 
fully specified. The server-side requirements aren't identical to the 
client-side requirements, but that's pretty normal. I don't really 
understand the problem here. Servers aren't ever going to receive packets 
they don't recognise in between packets they do; a packet a server doesn't 
recognise is a fatal error. This is unlike clients, who might well exist 
long after the protocol is upgraded, and thus have to be able to deal with 
any number of weird future servers gracefully.

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