[Web-SIG] WSGI middleware library
ianb at colorstudy.com
Tue Feb 1 00:28:13 CET 2005
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
* 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
* 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
More information about the Web-SIG