On 1/3/06, Ben Bangert <[EMAIL PROTECTED]> wrote: > > > I do actually get WSGI middleware. There are two issues: > > 1) CherryPy isn't fully compatible with Paste-Deploy (which I think is > > fixable, but is not yet fixed) > > 2) Usability > > #1 is a showstopper, but I do believe it will be fixed. #2 is not a > > showstopper, but it's an important consideration. > > Agreed, I hope #1 can be resolved soon, as I believe some of the > changes they're remedying will also make Routes integration better. > > Regarding #2, I had the same thoughts. I recently re-organized the > configuration for Pylons such that there's a very basic middleware > config file like so: > http://pylons.groovie.org/svn/trunk/pylons/templates/paster_template/+package+/config/middleware.py_tmpl > > It's about as basic and obvious as I could make it. Even if the > developer knows nothing about middleware it would be rather easy with > that layout to tell the developer how to add a new piece of middleware.
Yeah, that does seem fairly straightforward. I need to take a closer look at the Paste configuration system sometime soon and decide how I would deal with Paste config vs. CherryPy config. > > Sure. But, as I said, for important things that most people will use > > those features need to fit the TurboGears style. After that, if there > > are pieces that can be reasonably broken out and are useful for other > > folks, then I'm all for that! > > That's kind of what I was afraid of. TurboGears goes to some obvious > effort to re-use other projects in a rather seamless way, yet this > comment seems to indicate no effort will be spent by TG developers to > do the reverse... go to some effort to create re-usable parts rather > than building them into TG. I wasn't trying to make a point about willingness to invest effort. My point was that I don't want to sacrifice usability for TurboGears users for the sake of making components that are readily usable by other frameworks. For common operations, I want things to be as smooth as possible for TurboGears users. If that can be done in a reusable way, that's great! So, it's not about effort, but about API usability. As long as API usability needs are met, then being reusable is a good thing for everyone. To sacrifice on API usability means being less able to compete with Rails, for example, that doesn't have such a consideration. When it comes to the effort to create reusable APIs, you then get down to basic open source "itch-scratching". It's definitely the case that *I* am not TurboGears. Many parts of TurboGears come from other people, and to some extent reusability is going to depend on what people want to implement. I do think that more people would implement more reusable parts if WSGI middleware fit well in TurboGears (which it will once the Paste/CherryPy issues are done). Ideally, entire TurboGears apps would be easily pluggable into a WSGI-driven site. Kevin
