I posted this idea to the Web-SIG list, but didn't get much response (except from James Gardner, the author of pythonweb). But then, that list is kind of weird -- sometimes when topics come up I think everyone just happens to be paying attention to other things. Or at least, if I'm the one who brings up Topics Important To Me and I don't get a response, I make myself feel better by thinking that ;) And then I repeat myself here...

What do people think about collaborating on a kind of "standard" library of WSGI middleware? (Not standard like distributed-with-Python, just well publicized.) This is what I've tried to put together a little with WSGIKit, though not all parts of it would apply. And other people are, I think, starting to develop the same things, perhaps with some overlap. Maybe we can pool our efforts together.

The criteria I'd consider for components in this library:

• Should be something we could do Right, i.e., can become "complete". E.g., a proxying WSGI application could be complete. A commenting system can't.
• Shouldn't involve much UI. Mostly because it can't be very complete.
• Shouldn't be tied to anything very specific. E.g., if there's a templating middleware (um, don't ask me exactly what that would look like) it shouldn't be bound to any particular templating language. The specific bindings to specific templating languages should probably be part of the upstream libraries. (Except maybe some reference bindings)
• Provides robust architecture more than a pleasant API. E.g., WSGIKit implements Webware (more or less), but when you use that you see very little of the middleware that WSGIKit uses. And that middleware looks kind of ugly from an API perspective, what with the environment and its string keys and the sometimes funny semantics that WSGI implies.
• Be really well documented and stable (at least once we come to consensus on an interface), so that people could reliably and easily used these middleware components in their frameworks.
• Testable and tested.

Some candidates I imagine:

• Sessions middleware
• Logging middleware/library (based on the standard library of course)
• Error reporting middleware/library
• Test frameworks (?)
• A file application (handling If-Modified-Since, etc)
• A proxy application
• Libraries for parsing query strings and all that. Most of what is in Phillip's wsgiref.
• Authentication (this would be on the ambitious end)
• URL parsers (several, but maybe we could distill this down to a few primary models for parsing)
• And maybe a few of the more boring servers, like the CGI server, which will otherwise be homeless (or widely repeated).

I'd expect everyone involved in this project have ulterior motives, i.e., they'd all have their own separate pet projects and whatnot, and wouldn't be looking to this library (alone) to solve all their needs. And that would be good, another part of what would keep this from being Yet Another Framework.