Kevin Dangoor wrote:
On 1/30/06, Bob Ippolito <[EMAIL PROTECTED]> wrote:
This seems like a much simpler and more robust platform to build on
top of. It'd probably help out with performance too, since it
doesn't have all of that filter crap on every hit (which belongs in
middleware or decorators anyway, not per-object). I'd trade the
advantages of WSGI for the "stability"/ancestry of CherryPy any day,
but I'm not Kevin :)
That may be, but you *are* Bob. I tend to pay attention to your
opinions, because they're often pretty close to the mark.
As an aside to this, Christian *dowski has put forth a minor update to
the CP server that allows use of WSGI middleware with CherryPy:
http://projects.dowski.com/projects/cp_middleware_server
Something that struck me as a big gap in RhubarbTart is session
handling. Earlier today, though, Christian linked to a WSGI session
handler, so I guess there is something out there.
There's lots of things out there for sessions; I think this is a
relatively minor point, since RhubarbTart should be adaptable to any
WSGI session setup, and all it takes to WSGIify a session library is
very minor glue. The only session middleware I've really looked at is
flup, and there are some problems with it (mostly that the session is
loaded on every request, not on demand). Paste's built-in sessions are
also fairly crude. But stuff is out there, and how it is integrated or
what is chosen isn't dependent on RhubarbTart.
Generally speaking the design provides more free variables for
best-of-breed selection. No one piece is critically central (except for
the WSGI protocol, but that's a protocol, not an API). Even Paste is
used in relative minor ways -- the imports are all basic utilities
(e.g., parse form variables), or applying a default (and optional) set
of middleware to form the typical featureset of a framework. I think
additionally that the growing work and number of contributors in TG
makes it critical that there be more internal decoupling, with possibly
differing release schedules.
Also, regarding stability, Julian has been adding very good test
coverage for RT, so I think it will be quite stable. Testability is
aided by the fact that RT is very small.
Here's my philosophy on stuff like this: I aim for TurboGears to be
best-of-breed. The definition of "best-of-breed" will change over
time. (It'll also vary from person to person, but there's not much I
can do about that.) As "the best" changes, I'd like to see TurboGears
change with it. Of course, changes need to have reasonable migration
paths and all of that, which is the primary limiting factor. But, the
bigger the win, the easier it is to justify a slightly more painful
transition.
We talked about this stuff some in a private email. I didn't propose
anything before 0.9, except hopefully some changes so that applications
written against 0.9 won't require major updates (maybe any updates) to
work with a possible future TG+RhubarbTart combo.
My experience with CherryPaste showed a couple different problems:
* Identifying the base of the application. request.app_url is really
easy to support (and RhubarbTart includes that). I think there was a
proposal about an additional attribute on controllers (is_root_app or
something), and that would also be easy to support. I'm baffled how
tree.mount is supposed to be used, though I suspect it will be hard to
support.
* Serving static files. Static file serving as a filter seems rather
weird to me. Ideally, I'd like to see:
static_dir = os.path.join(os.path.dirname(__file__), 'static')
class Foo:
static = turbogears.StaticDir(static_dir)
# or maybe, for using pkg_resources:
static = turbogears.StaticDir(__name__, 'static')
I don't know what's considered best practice right now, but CatWalk's
registering of static-file-related configuration when you get the index
page was particularly hard to deal with.
* Imports of CP HTTP-related exceptions, and cherrypy.request/response.
These are fairly trivial, since changing "cherrypy" to "rhubarbtart"
will mostly work (and whatever differences are there can and should be
fixed). If TG insulated this (e.g., you import turbogears.request),
then applications might require zero changes. RhubarbTart could also
provide a cherrypy module for backward compatibility, but I'd really
rather not (unless perhaps it was explicitly enabled by the app and
spewed warnings).
* Filters. CP-style filters could be implemented in RhubarbTart, but
I'd rather just not. The filters in TG could be reworked or have extra
interfaces to be phrased as WSGI middleware. I think the actual
application-facing interface to things like Identity don't need to be
changed, so this might not be an issue. Since TG uses decorators more
than filters (for app-visible APIs), I think this is mostly OK as-is.
There might be other aspects, but those are what I hit. I think most of
these changes have merit regardless of the underlying framework. Many
of these issues are also things that CherryPaste has a hard time working
with.
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
