[Web-SIG] Preferred set of WSGI servers

[Ian Bicking]

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?