The more I think about it, the more I get the feeling that CherryPy
filters should have been Paste middleware (or alike) : completely
independant components, just piped from one into another by
configuration data.
Actually, this is more or less the way it is. This stuff is just
automatically configured in, and maybe *that's* the problem.
Don't want Identity ? no prob, just remove it from the pipe.
Want FooBarFilter after static and before Identity ? just declare it
this way in the pipe.
If you look in turbogears/startup.py, you'll see that the identity
filter is added directly to _cpFilterList on the Root object. That's
where the pipe is.
Sorry to hijack a thread, but I have had a similar thought in the
back of my mind for some time now, and this post really brought it to
the forefront.
I think TurboGears is missing an opportunity with WSGI at this
moment. Bigtime. Sure, you can do all sorts of WSGI things with
TurboGears, but it doesn't seem to be utilized nearly as well as it
could be, or seem to be the core foundation that TurboGears builds
upon. I think it should be! What do I mean? Well, it means a lot
of things, not limited to the following:
1. TurboGears applications should *always* be deployed as WSGI
applications.
2. TurboGears applications should *always* be started through
something like Paste Deploy, which smart backends for:
- SCGI, FastCGI, or HTTP Proxy.
- Threaded, forking, or asyncore-based.
No more generated startup scripts, just pick a deployment path
and start through paste.
3. Everything that can be implemented as WSGI middleware instead
of CherryPy filters absolutely should be. Everything. These
can be easily chained with Paste Deploy, giving us all sorts
of power, and opening up TurboGears features to other
frameworks, and other framework's features to us.
4. The ToolBox should have the ability to create deployment
scanarios from templates, like "threaded SCGI behind lighttpd,
with the X, Y, and Z middleware enabled" or "asyncore proxy
HTTP server with X and Y middleware enabled."
5. It would be nice to be able to use the ToolBox to tune the WSGI
pipeline at runtime.
WSGI is a huge huge advantage of TurboGears over competing frameworks
in other languages (like Rails), giving you powerful ability to chain
together WSGI middleware, and share huge chunks of code between all
sorts of different projects.
I know that a lot of this is already happening, but I think that WSGI
is the killer app of Python for HTTP applications (notice, I didn't
say "web" applications), and there is a lot more that could be done.
I would love to see a brainstorm of what could be done with
TurboGears if we focused on WSGI post 1.0 -- especially from guys
like Phillip Eby and Ian Bicking, who clearly have thought about this
far more than me.
Again, sorry to hijack the thread for my own rambling, but I think
this needs to be discussed at some point.
--
Jonathan LaCour
http://cleverdevil.org
