Re: [hybi] Extensibility mechanisms?

[Ian Hickson <[e-mail]>]

On Sun, 18 Apr 2010, Scott Ferguson wrote:
> 
> The client and server APIs must be suitable for amateur programmers, and 
> the wire protocol must support those simple APIs, but it's _not_ 
> important that the wire protocol be implementable by someone who can't 
> understand buffering, chunking or encoding. After all, HTTP/1.1 requires 
> those capabilities.

IMHO, HTTP is a disaster in terms of getting multiple server-side 
implementations. Over three quarters of the market is dominated by two 
vendors, and the third largest vendor on a per-server basis is a company 
that runs a proprietary implementation and derives significant benefit 
from being able to do so. There are some custom servers, e.g. in some set 
top boxes or other network devices too small to run one of the few common 
servers, and many of those are highly incomplete or buggy implementations.

I would not consider HTTP a model solution here. On the contrary. Its 
complexity has led to a rather stagnant monoculture which is an attacker's 
dream. A single exploit can affect millions of servers.


> The "long tail" in HTTP is enabled by the server APIs: CGI, mod_xxx, PHP,
> Servlets, ASP, etc, and the client javascript API. It is indeed very important
> that the server-side and client-side APIs for WebSockets be usable by hobbyist
> programmers to do simple things.
> 
> However, the "long tail" are not writing hobbyist HTTP client or server
> protocol implementations.

That's because HTTP is too complicated. If we make Web Socket simple 
enough on the server that it's just as easy to roll your own Web Socket 
server as to use an HTTP framework today, then I see no reason why the 
long tail shouldn't write hobbyists Web Socket servers.


> In addition, WebSockets is intrinsically multithreaded, which makes the 
> claim that it's aimed at amateur implementers bizarre.

It's relatiely straight-forward to implement Web Sockets using a select(3) 
loop, no need for threads.


> WebSockets requires threading/async handling on both ends, which is 
> beyond the capabilities of these hypothetical amateur programmers who 
> cannot encode a simple frame.

The difference is that writing a select(3) loop is something you can learn 
from tutorials then implement with trial and error, and without which your 
server will not work at all; while getting text length encodings right 
requires asking questions that many ASCII-only authors will never know to 
even ask. (This is less of a problem in locales where non-ASCII characters 
are common, of course, at least for authors who use this feature to 
transmit natural language text.)

Actually measuring lengths is relatively straightforward in most languages 
once you know you have to do it.

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