-> > 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. -> -> Adding support for mod_python in the stdlib seems excessive -- -> shouldn't that be included with mod_python instead? FastCGI OTOH seems -> handy to have. -> -> See my response to Ian recommending a conservative approach here.
A *very* conservative approach would be to include a simple WSGI_HTTPHandler class based on BaseHTTPServer (much like SimpleHTTPServer), and that's it. This is my favorite option... While there are many additional handlers one *could* add in, it's not all that tough to include the necessary machinery in one's own package. I'd shy away from FastCGI and SCGI (even though I like them both) simply because it's easy enough to get adapters and it seems like an undue burden on *someone* to put them into the Python distribution. cheers, --titus _______________________________________________ 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
