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 / [EMAIL PROTECTED] / http://blog.ianbicking.org _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
