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

[Maciej Stachowiak <[e-mail]>]

On Jul 26, 2010, at 3:42 AM, James Graham wrote:

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

Actually, I used the word "professional" because that sentence was a literal quote of something Ian said. I don't think "professional" vs. "amateur" is the best distinction to make. There are many expert programmers who work on projects that they are not paid to work on.


> 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

I would expect a lot of people bypass all of these steps and go straight to:

4) Use a library, framework, or modular server that someone else has written.

As one anecdotal example, I would cite the fact that I have written or modified a number of scripts that serve dynamically generated HTTP resources in Perl, Python, PHP and Ruby, but I have never done steps 1-3 in any of these programming languages. I have also written an IRC bot purely as a hobby, and in that case too I used someone else's library rather than any of steps 1-3.

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

Are there any network protocols that it's common to implement from scratch (using any of the levels 1-3 you mention above) in production code, rather than using someone else's library? Is there any common application-level protocol (say "QQP") where searching for "Python QQP" will land you at the sockets tutorial rather than a QQP library? That would be more convincing evidence.

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

Out of the existing requirements, the one that this statement is most likely to conflict with is security, since many proposals for making the handshake secure against cross-protocol attacks involve crypto. I would not consider efficient implementability in scripting languages to be a higher priority than security. I think other proposed features that conflict with the simplicity argument are not especially inefficient to implement.

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

I don't think anyone has a problem with simplicity as long as it doesn't trade off against other requirements that they hold to be important.

I do think simplicity is important, but I hold some requirements as important enough to be worth significant amounts of complexity; for example the security requirements.

Others may hold different requirements as important, and I don't think appealing to some standard of simplicity will make anyone conclude that their particular requirement is less important. If we want to limit protocol complexity, we have to prioritize the requirements, or have some good story to tell about how some requirements can be addressed on top of the protocol instead of built-in.

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

The last version of Safari shipped with a version of WebSocket that is incompatible with the current protocol. So we are open to further changes, if they are valuable. I don't think we are yet at the point where incompatible changes are inordinately expensive. I don't think the protocol has enough real deployment experience for us to lock it down.

Regards,
Maciej