[Web-SIG] FastCGI (previously "A query for hosting providers")
Ian Bicking
ianb at colorstudy.com
Fri Apr 1 21:05:27 CEST 2005
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
More information about the Web-SIG
mailing list