[Web-SIG] WSGI in standard library (was: A trivial template API counter-proposal)
ianb at colorstudy.com
Sun Feb 5 00:07:21 CET 2006
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
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):
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
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
More information about the Web-SIG