[Web-SIG] WSGI middleware library

[Ian Bicking]

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
> extensibility.

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
> code.

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