[Web-SIG] FastCGI (previously "A query for hosting providers")

[Ian Bicking]

A.M. Kuchling wrote:
> In a little thread at
> http://www.livejournal.com/users/zestyping/101939.html, effbot thinks
> about creating another framework ("ElementWeb, anyone?").  I thought
> about that a little -- what would a blank-sheet-of-paper ElementWeb
> look like? -- but then decided that it's simply not possible.
> 
> I mean, here are the requirements for how to run applications:
> 
> 1) Has to be easy to install and configure
> 2) Has to be installable on hosted services (where you can only upload stuff, 
>    not run separate processes)
> 3) Has to be high-performance.
> 
> SCGI fails 2); FastCGI fails 2), and may fail 1); standard CGI meets
> 1) and 2) but fails 3); mod_python can fail 1); running an HTTP server
> and using proxying fails 2).  There's no good solution.

You simply can't have 2 and 3 simultaneously.  mod_php is a model, but I 
don't think mod_python looks like mod_php to hosting providers -- it 
looks more like mod_perl (which, AFAIK, is not available on commodity 
hosts).  OTOH, it might be reasonable to offer a couple options, 
including CGI (with a performance penalty tied to application 
complexity) and some other options like SCGI, FastCGI, HTTP, etc.  Each 
is a compromise of sorts, but if it's easy and reliable to move around 
that would be okay.

In some ways easy HTTP serving makes 2 less important, because cheap 
hosts are in some ways an area for people to experiment, and an HTTP 
server makes it easy to experiment on your own computer.  It still keeps 
someone from creating a phpBB-like program for Python and having people 
throw it up on any little site, but that's not low-hanging fruit at this 
point.

I've been thinking about putting together more server/client glue in 
WSGIKit.  Right now invocation looks like:

server.py --server=twisted --webkit-dir=path/to/app

I'd like to support more servers and also more frameworks.  One server 
would be "cgi-script", which wouldn't be a server so much as a CGI 
script builder (where the CGI script would just be the right #! line, 
some sys.path manipulation, some configuration setup, and the WSGI 
cgiserver invocation).  One can imagine the same thing using one of 
those all-in-one CGI script builders (mxCGI or something?) that packages 
everything up into a zip file that can be uploaded to another host.

There's nothing magic about the server.py script, of course, except that 
it doesn't try to be magically pluggable or anything, just hard coding 
the glue necessary for existing code.  I think this less impressive 
direction is more achievable at this point, and gives a good new-user 
experience.  I'm actually thinking that, given a few simple standards 
(common configuration, this server invocation script) the proliferation 
of frameworks isn't so bad as long as we continue to refactor and 
consolidate the easy parts.

-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org