I posted this idea to the Web-SIG list, but didn't get much response (except from James Gardner, the author of pythonweb). But then, that list is kind of weird -- sometimes when topics come up I think everyone just happens to be paying attention to other things. Or at least, if I'm the one who brings up Topics Important To Me and I don't get a response, I make myself feel better by thinking that ;) And then I repeat myself here...
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 for components in this library:
Some candidates I imagine:
I'd expect everyone involved in this project 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.
You're spot on about the mailing-list, at least in my case. Too busy. Not to mention the general expectation in OSS discussions: if you open your mouth, expect to get assigned more work. :)
Although I'd like to see some standardized middleware, I'm more interested at this stage of WSGI to get the major servers on board (Apache 2 being first on my list). But you didn't hear that from me; I have enough to do on those "other projects".
Better applications means more motivation for better servers. Or vice versa -- either way, working on one doesn't keep anyone from working on the other; quite the contrary! And because WSGI is a stable target for both sides, they can work happily and safely in parallel.# Ian Bicking
...just saying that my time is a limited good. So if _I_ work on one, _I_ can't work on the other and still expect to continue getting paid for my day job. ;)
Hence the silence.
FastCGI is orthogonal to WSGI. WSGI is a way Python applications and servers can communicate in the same process. The "server" may just be something accepting FastCGI connections, or might be a real HTTP server, or whatever. So WSGI is an internal API, not a protocol.# Ian Bicking
For my thoughts see http://42.blogs.warnock.me.uk/2005/02/a_wsgi_referenc.html
Possible other addition:
- Static caching middleware
ie, some standard way, Done Right, to cache pages on a dynamic site that haven't changed since the last access.
If there's anything middleware Done Right would be useful for, it's this. Unfortunatel I don't have much experiance with this sort of thing to offer to do it myself, but I'd definitely take it up if it were around...