[Web-SIG] WSGI Servers

[Ian Bicking]

David Warnock wrote:
> Everyone else may disagree but it seems to me that servers are where the 
> remaining big gap is for wsgi.

Oh, I'd probably agree, there's a lot of things on the server end of 
WSGI which are unanswered.  I guess this list that I wrote a while ago 
covers some of the things like I'd live:

http://blog.ianbicking.org/an-ideal-python-web-programming-environment.html

WSGI only helps in that it separates concerns -- many of these issues 
could be addressed purely on the server side, for any framework.

> What I want is to be able to pester hosting services to provide a really 
> good, fast, reliable wsgi standards compliant server. I don't care if 
> the application deployment is non standard, as long as there is one and 
> I can do it without shell or root access. I don't care if I have not got 
> plugins, filters etc standardised yet (as long as I will have some way 
> to add them without shell or root access).

I think this is pretty hard, though clearly worth the effort.  From a 
hosting perspective:

1) It should work with a single Apache server with multiple clients. 
Obviously it's better with a single server per client -- e.g., clients 
can have their server run as different users (instead of everyone 
sharing the nobody account).  But that's not the typical way commodity 
hosts are set up.

2) It should work with Apache 1.3, since that's used heavily, even if 
Apache 2 has some potentially useful capabilities.

3) It shouldn't require manual server restarts or resets, edited code 
needs to update itself transparently.

4) It needs some automatic monitoring, e.g., if you have an infinite 
loop or some memory explosion, it has to degrade gracefully -- aborting 
the request, and continue to serve other things for the client.  Maybe 
there'd be some collateral damage for the client -- a few other lost 
requests -- but other clients can't be effected.

5) It shouldn't need complicated Apache configuration; preferably 
nothing, or configuration that can go in an .htaccess file.

6) It shouldn't be horribly inefficient.

CGI is great except for 6.  mod_python isn't very good for 1-4, AFAIK. 
Separate threaded processes (like Zope or Webware) are problematic for 3 
and 4.

In theory something FastCGI-based should be able to do this.  I don't 
know of any commodity hosters that support FastCGI, though maybe even 
now you could use one of the CGI->FastCGI adapters, let the host kill 
processes as they will but reuse processes to the degree possible.  (Or, 
if not FastCGI, something like it -- if you are using a CGI gateway it 
doesn't matter if you are using a standard.)

Oh, but wait:

7) Not require shell access or a compiler.

There's actually a good chance you could get away with this, finding a 
precompiled FastCGI CGI script that would work and uploading it to the 
cgi-bin directory, though your URLs will look kind of bad (barring a 
host that allows rewrite directives in .htaccess files).  Still, it's 
not very easy; could it be made easy with a smart enough installer?

Or, there's the possibility that FastCGI could be utilitized in a robust 
enough way to handle all this, and hosts could support it with good 
enough instructions and with enough user demand.  In that model, maybe 
you could just drop an appropriate file into your site and make it work.

Or, something other than FastCGI, maybe as an Apache module.  Not 
mod_python, since the idea is to run in a separate process, and mostly 
do what FastCGI is supposed to do, but maybe in an easier-to-understand 
and easier-to-maintain way.

Or, mod_python made to look more like mod_php, that is, more robust and 
partitioned.  I think this might require changes to the Python 
interpreter itself, so I don't know much about feasibility.  I also 
don't know a lot about mod_python, so maybe it's better this way than I 
think.  I see it like mod_perl, which despite its age generally isn't 
available on commodity hosts AFAIK.

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