-> 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 / [EMAIL PROTECTED] / http://blog.ianbicking.org _______________________________________________ Web-SIG mailing list [email protected] Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
