[Web-SIG] WSGI middleware library

[Ian Bicking]

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:

* 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. 
Those kind of bindings should probably be part of the upstream libraries.

* Provide 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, what with the environment and string keys and the 
sometimes funny semantics.

* 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 to 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.  Together this should be attractive to people who 
like to delete code ;)  (Code deleted is code debugged!)

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