[Web-SIG] WSGI middleware library
ianb at colorstudy.com
Fri Feb 4 19:04:57 CET 2005
Titus Brown wrote:
> -> What do people think about collaborating on a kind of "standard" library
> -> of WSGI middleware?
> Hi, Ian,
> ok, here's another response ;).
> I slept on it a bit, and I would like to suggest one modification: make
> it a cookbook of examples, rather than a library.
> This implies that we don't need to have a standard naming scheme or a
> common coding style to the components, and there can be redundancy --
> multiple examples overlapping in functionality. It also means that
> there is room for "incomplete" solutions, which are IMO of great
> value even just as stubs. Such code can be isolated and used piecemeal,
> independently of the rest of the library. And, finally, it means that
> code can be designed strictly for functionality rather than for
Obviously some of the solutions will be incomplete for a while -- the
development is a process. And there's nothing keeping us from having a
contrib/ directory in the project, which could contain any kind of
example or tool that might seem useful. There's no reason to exclude
anything useful, but putting code in a library implies some committment
to the API and functionality, which isn't appropriate for some code.
That can largely be solved through documentation and other metadata
(like the directory layout).
As for extensibility... well, hopefully some pieces won't require much
extensibility besides really obvious hooks that you'd want to include
anyway. And hopefully those would stablize once a few people tried to
use a piece of middleware and suggested improvements -- part of why I
want to do this collaboratively is because predicting places for
extension tends to be inaccurate, while waiting for people to use code
and find they require a place for extension usually works better.
> I make this suggestion for two reasons: first of all, I'd be more
> interested in contributing code to a cookbook than to a library,
> for the above reasons. And, secondly, my limited experience with
> example code I've posted suggests that people are primarily interested
> in a complete, functioning example that's isolated from other
To a degree, I would hope we'd have functioning examples by design --
certainly a smaller number of dependencies will make the libraries more
accessible. At the same time, though, I want to actually *use* the
results. E.g., there's things I'd like to move from WSGIKit to this
library; but if this isn't a real library then all I can do is copy
items and maybe keep them in sync in the future, but I can't every *use*
them because a cookbook isn't stable or even packaged.
> I do think a test harness (to make sure that the middleware is WSGI
> compliant) and a documentation standard (reST? In each directory?
> or ...?) would be a good idea.
wsgikit.lint does some compliance testing, when used in conjunction with
other tests. There's no general way to poke at middleware or
applications, so we have to rely on specific code to do the poking while
another piece of code (lint) makes sure everything goes through properly.
Other parts of a framework would certainly be useful. Adding a wsgi:
method to, say, mechanize or urllib2 would be nice; it would save you
from having to do any server setup and test the WSGI application directly.
> As immediate candidates for inclusion I suggest:
> * a simple wsgi-passthrough middleware, that "handles" the data without
> modifying it. (The idea is to provide hooks where I/O *can*
> be modified.) Most of my time in wsgiComment was spent figuring
> out how to get that functionality.
> * the CGI server from the PEP.
> I can submit nicely formatted versions of these if you're interested in
> proceeding immediately; I'd also be happy to host a Darcs repository for
> the stuff ;).
I was thinking of putting it on svn://w4py.org; I'm a bit partial to a
centralized repository for this sort of thing, since it encourages
continuous integration and maybe is a bit more transparent. And svn is
pretty common at this point.
Ian Bicking / ianb at colorstudy.com / http://blog.ianbicking.org
More information about the Web-SIG