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

[James Graham <[e-mail]>]

On 07/26/2010 01:07 PM, Maciej Stachowiak wrote:
>
> On Jul 26, 2010, at 3:42 AM, James Graham wrote:

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

To be clear here, I mean "efficient in terms of programmer time". That 
is, I don't think it is acceptable to make would-be implementers write 
substantial amounts of code that are not directly related to websockets 
just to write a simple websockets server.

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

That could be true, but it is sad if so; I would hope people are capable 
of assessing the relative importance, and relative complexity, of 
features that they would like in the protocol.

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

I think one browser shipping doesn't create an ecosystem that depends on 
WebSockets not undergoing incompatible changes (although I note that I 
have seen multiple people ask how to make their servers compatible with 
both -75 and -76 handshakes in order to work with both Safari 5 and 
Chrome). I think that many browsers shipping compatible implementations 
is highly likely to create such an ecosystem. Therefore I would say that 
the timescale for substantial changes to websockets is soemthing like 
the release timescale of the next generation of browsers minus the 
stabilization time and the time needed to implement changes. It seems to 
me that that timescale could be rather short.