Re: [hybi] Is there a traffic jam?

[Jamie Lokier <[e-mail]>]

Ian Hickson wrote:
> I agree. But who mentioned scalable TCP servers for binary protocols? I 
> want to let people like my dad write little scripts that do insignificant 
> little things, just like today people write CGI scripts for all kinds of 
> stuff. I want to let 12 year olds write multiplayer games. I want to let 
> someone who picked up HTML on Monday and CSS on Wednesday try their hand 
> at WebSockets on Friday. I want to support the intern whose boss told him 
> to put one of those interactive chat widgets on the intranet.
> 
> > This is likely to require multi-threading in most languages.
> 
> It's easy to write simple TCP servers using a select() loop without 
> threads.

It's easy to write a simple HTTP server using a select() loop too, if
you know unix, or Perl, or Python.  There are lots of bad ones around
to prove it.  It's even easier with fork().

But mostly people use big HTTP servers written by other people and hang
applications off the back now, using CGI/FastCGI/WSGI/mod_*/ etc.

I expect your dad / 12 year old / person who picks up HTML on Monday
will use Apache or similar with a CGI or similar backend to their
favoured programming language.

They probably don't care much about HTTP, just that it calls their
application when a page is requested.  And they probably don't know
anything about unix system calls.

So on Friday they'd rather use Apache with a "hybi-CGI" backend to
their favoured programming language, than write their own select() loop.

The important thing for that scenario is that "hybi-CGI" must be easy
to understand and use.  Whether that's because it's so trivial anyone
can write TCP/WebSockets in good programming languages, or because the
protocol fits into widely used CGI-like frameworks in a way people
understand.

Right now, AJAX is widely used, and polling-AJAX is widely used for
server-driven updates to web pages because people find it easy to
understand, and it's easy to use existing frameworks - just another
tiny web page (fragment) to serve.

Indeed a lot of people think polling-AJAX is the most efficient way to
keep bits of a web page updated.  From a CGI-writing point of view,
that's true.  (From my point of view it's obviously false.)

For those people (imho the majority), what's most important is that
their preferred CGI-like framework supports the new protocols and
doesn't change the way they program too much.

Of course we'd like to support people who are happy writing their own
low-level server implementations too, and work well in that case.

> To reiterate: I have no objection to there being many protocols 
> standardised here. But I do want to make sure that at least one of them 
> enables an inexperienced programmer to bang out an interactive toy in a 
> few days without having to use libraries, just like they can bang out a 
> CGI script today and get interaction in forms. Currently, of the various 
> proposals, only one of them comes even close to this, IMHO.

Which one?

(I've designed my flavour of asynchronous HTTP to fit banging out
extended-CGI/etc. services like a glove, while also addressing
TCP-style streaming/messaging services.  I think WebSockets (without
metadata) does not fit the CGI-style usage as well, but it's
interesting to see the perspectives and differing requirements being
expressed.)

-- Jamie