Re: [hybi] Protocol simplicity and the "amateur programmer" standard

[James Graham <[e-mail]>]

On 07/26/2010 02:43 AM, Maciej Stachowiak wrote:

> * Keep the protocol as simple as possible to limit the number of bugs
> that professional programmers make.

As I previously said, I think that framing the discussions in terms of 
"professional" vs "amateur" is the wrong way to go. After all one can 
find "amateurs" who are much more capable than many professionals. Using 
these terms appears to be divisive; I believe that you would not have 
used the term "professional" in the above description if it were not for 
the fact that Ian had previously used "amateur"; rewriting you principle 
as "Keep the protocol as simple as possible to limit the number of bugs 
that implementors make." is largely equivalent but less pejorative about 
non-professionals.

Having said that, I think a different goal would be a better statement 
of Ian's intent:

"Websockets should be the minimal layer on top of TCP needed to meet the 
additional requirements of browsers"

I think that neatly folds in the "amateur programmer" requirement 
because if one has a minimal layer then it is, by definition, as simple 
as it can be. You might disagree on the basis that you believe that 
inexperienced people don't use low-level primitives for network 
programming. However I would contest that the typical progression for 
someone learning network programming in a language such as Python is:

1) Use the socket module and low level primitives. Implement simple 
applications with no difficult scaling requirements

2) Learn a library that abstracts away the sockets and has nice scaling 
properties (typically at the cost of some complexity of a different 
type) e.g. Twisted or Diesel

3) Author a library that abstracts away the raw sockets

As, admittedly rather weak, evidence for this hypothesis I note that a 
Google search for "python networking" returns — at least for me — [1] as 
the top hit, which is a tutorial for the low-level sockets / select 
functionality. I would expect people new to server implementation 
writing WebSockets applications to follow a similar progression. In this 
regard, I think the comparison to HTTP, where people do typically reuse 
an existing server, is somewhat misleading because applications using 
WebSockets are likely to be more different than applications using HTTP 
because WebSockets applications have to implement their own 
application-level protocol whereas HTTP applications do not.

Even if my hypothesis is faulty and people go straight to phase 2 above, 
designing the protocol as if they went through phase 1 seems harmless, 
whereas if they would naturally go through phase 1, forcing them to go 
straight to phase 2 because of complexity in the protocol seems bad.

That said, I think some complexity in the handshake is more acceptable 
than complexity elsewhere because one can imagine a library that is a 
very thin wrapper over raw sockets, just dealing with the handshake and 
little else. Nevertheless, I think a good yardstick requirement should be:

"it must be possible to efficiently implement WebSockets using only the 
stdlib of today's popular scripting languages without dropping down to 
lower level (C, Java, whatever) code"

It has been argued that an explicit statement of simplicity is not 
needed since simplicity is an obvious requirement that you can optimise 
for once all other requirements are in. I believe this to be untrue. I 
think collecting a laundry list of requirements and then trying to make 
a protocol that satisfies them all will not result in anything simple. 
Instead one must determine which additional requirements one can forego 
in order to preserve simplicity.

Having said all of that, I think the current discussion on this list 
belies a false belief that we are still at a stage where the protocol 
can be trivially changed. Instead we are in a situation where there are 
three known implementations in major browser engines (presto, gecko, 
webkit) and some of those are close to shipping. There are also numerous 
server implementation. At this stage, the cost of substantial changes is 
already looking prohibitive and if Opera/Firefox/Chrome/Safari all ship 
with interoperable support, we can assume that substantial changes to 
the design will become all but impossible since browsers rarely rescind 
functionality that is needed to keep sites working.

Given the current implementation status, I suggest people adopt the 
attitude that changes are difficult and expensive and only the most 
necessary changes should be advocated. If there are people who believe 
that WebSockets has the wrong requirements, or occupies the wrong part 
of design space, it seems more prudent to work on a seperate, parallel, 
proposal.

[1] http://ilab.cs.byu.edu/python/