[Web-SIG] WSGI in standard library (was: A trivial template API counter-proposal)

[Ian Bicking]

Phillip J. Eby wrote:
>> Perhaps wsgiref
>>should go into the Python 2.5 standard library?)
> 
> 
> Sure.  I'd suggest that we might want to expand it a little to include some 
> of the fine contributions of other authors, such as Ian's "lint" middleware 
> (which sits between an app and a server and checks both for compliance) and 
> maybe even his "Python debugger in the browser" middleware.  There have 
> also been people who've written a few utilities for CGI-in-WSGI, WSGI in 
> mod_python, etc.  And it'd be nice to squeeze in a FastCGI implementation 
> if somebody's got a suitable one.  Docs are also nonexistent at the 
> moment.  I'd be happy to co-ordinate and consolidate the additions, and of 
> course I'll write documentation, though any assistance people can offer 
> would be greatly appreciated.  Some people have written nice WSGI tutorials 
> or explanations, so if anybody wants to offer those up for consolidation 
> into docs, that would be good too.

There's some pieces that I think are not yet ready for standardization. 
  For instance, the error catching middleware would deserve a much 
larger discussion, I think, as it also involves the question of how to 
extend tracebacks (it uses Zope's code that uses magic local variables). 
  Also, the interactive implementation is complex enough (including 
Javascript) that I can't envision it stabablizing sufficiently.  (Paste 
includes a cgitb-based catching middleware as well)

I think a WSGI-based HTTP server is fairly easy to stabalize.  Clark 
Evans contributed a server based on SimpleHTTPServer, which I think is 
both pretty complete and doesn't do anything besides HTTP serving (e.g., 
no static file serving): 
http://svn.pythonpaste.org/Paste/trunk/paste/httpserver.py

The CGI server in wsgiref is also very stable -- there's not much for it 
to do.  Flup includes FastCGI, SCGI, and AJK, both forking and threaded. 
  I think all these pieces have relatively few dependencies, which could 
be extracted.  No forking WSGI HTTP server exists that I know of.

paste.lint is pretty stable and complete, I think.

With a little adaptation, paste.urlparser.StaticURLParser and 
paste.urlparser.PkgResourceParser also could be useful -- these are 
static file serving apps (they should be renamed, of course).  Serving 
with pkg_resources doesn't make sense unless pkg_resources is in the 
standard library.  But both those are based on paste.fileapp.FileApp -- 
which serves a single file -- and while Clark has also done some work on 
that and it is improved, I feel less confident that it is complete (but 
it could be completed -- its scope is well-understood).  Finding a file 
is easy (that's what StaticURLParser does), but actually serving a file 
with full HTTP support is a little more complex.  Also support for 
encoding and expiration times is missing from those -- mostly a matter 
of passing related configuration.  I think a good static file serving 
implementation is really valuable.

paste.cgiapp is relatively simple (runs a CGI script).  I think 
paste.proxy (just added) would be a really nice contribution to the 
standard library -- an HTTP proxy to another server, appearing as a WSGI 
application -- but the implementation is rough and only a couple of days 
old.

There's also a bunch of the routines in paste.request, paste.response, 
and paste.wsgilib could be good for the standard library.  There's also 
some code in paste.httpheaders, which perhaps could be made simpler and 
more primitive-feeling -- for things like parsing header values 
according to their meaning in HTTP.

There's several other bits of Paste that are pretty straight-forward, 
but not necessarily important.  E.g., a middleware that profiles the 
internal request and includes that in the output.  And some parts that I 
think are really useful, but abstract in a way that might not make 
everyone comfortable -- like paste.urlmap for mounting applications, or 
paste.cascade for trying multiple apps in a row until one "succedes" 
(where success usually means doesn't-return-404).

If stuff was put into the standard library, I think it would be 
important to consider up-front how the code would be backported.  I'm 
not really happy with the ad hoc backporting of libraries that currently 
occurs.  And I don't want to maintain the same code in Paste and a 
standard library module, or use cascading imports in my code.

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