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 | [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
