Here's the full set of WSGI-enabled servers I'd like to see (and in some way encorporate into Paste, of course):
* CGI gateway (done: not sure of canonical location) * Simple threaded HTTP server (done: wsgiutils) * mod_python (?) * ISAPI (done: http://isapi-wsgi.python-hosting.com/) * Zope product (not done)
Those are all rather specific to certain environments. Then I'd like to see two other servers: multi-process and threaded. Obviously the two imply very different architectures. Well, maybe not, but it seems like it to me.
Right now we have several servers with different purposes: SCGI (one for forking and threaded each), FastCGI, HTTP, etc. I don't really like that, I feel protocol support should be a separate concern. I would like for the two "preferred" deployment servers to support this set of protocols:
* HTTP * HTTPS * FastCGI * SCGI
Support for other protocols like FTP doesn't hurt, of course, but their exact relation to WSGI is unclear. Right now servers seem to be FastCGI-ish (which includes SCGI) *or* HTTP. I don't think this protocol choice should restrict the server choices. I think FastCGI-ish setups can be easier to configure an integrate; other people may disagree, but I don't see any technical reason not to include all these protocols, so why not make everyone happy? (Note that I'm personally not concerned about the fancier features of FastCGI specifically, like starting processes and doing pooling as part of the protocol; I'm only interested in the delegation of requests to different processes.)
Twisted is an obvious contender for the threaded server. However, to my knowledge it does not support FastCGI or SCGI (as a client). Also, WSGI support is only available for twisted.web2, which doesn't have a release yet. Lastly, the installation isn't as easy as it could be -- it requires Zope interfaces, which includes C extensions. So, there's some work to be done there. To their credit, with the recent split of Twisted into smaller packages they are moving in the right direction. Medusa is a simpler alternative; it's not as actively maintained, but there aren't as many packaging or dependency issues.
For the forking server, I really have no idea. There's several out there, but I don't know about all the features that are desirable or implemented. Several of the servers don't speak HTTP. I can't make any specific criticisms, because I don't even know what to look at.
Lingering in the background of these server discussions are issues like user isolation and module reloading (and/or server restarting).
Thoughts, reactions?
_______________________________________________ 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