At the risk of offending you guys with my continual blabbering, I do
like the "tools not policy" approach shared by the FreeBSD and Mason
worlds.
This is exactly what I see WSGI accomplishing. It's too lame of an interface to be anyone's policy (in a good way, of course). It's always been possible to use external libraries, but it's difficult to use libraries that participate in the request/response cycle, and WSGI makes that possible.
This can be used in both mundane and interesting ways. I think sessions are a bit mundane, but they work well, allowing the session "library" to modify both request and response, providing an isolated and well-scoped way to add session services to a WSGI application. This doesn't preclude such a library (middleware) relying on other libraries for the bulk of their work (e.g., persistence); indeed, I think it's best to keep middleware as small as possible.
A more interesting example of this kind of reuse is URL parsing. Typically URL parsing is one of those intimate details of a framework that can't be factored out. But paste.urlparser.URLParser is fairly successful, I think, at implementing a specific algorithm without greatly effecting other parts of the system; it doesn't make any assumptions about the applications it delegates to, or about the environment it is run in. It's not the only URL parser you'd want -- but that's a big part of what makes it interesting; it separates one kind of policy (URL resolution) from another (how resources are expressed).
I think other people have worried that this sort of thing is all fun and games, but it doesn't give us a concise and unified framework. But by firmly keeping policy either decoupled (urlparser) or entirely removed (session middleware) it makes it possible to create a framework that is the amalgam of these pieces of code without sacrificing internal consistency.
-- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
