TG 1.x & use_wsgi_app
Ken Kuhlman
"use_wsgi_app"-type functionality to tg1.1b2, if I should hold off
until 1.5, or even if it's a mis-feature that shouldn't be backported
at all.
As a memory refresher, "use_wsgi_app" is a TG 2.0 feature that is used
to return a WSGI application from an exposed controller, and the
ticket for backporting it to TG 1.x is #1951. Anyway, here's why I'm
struggling:
(a) I'm not sure that use_wsgi_app's interface is right. I think it
would be better if it allowed the WSGI app to be used directly from a
controller. For example, instead of this:
class MyController(Controller):
@expose()
def some_controller(self, *args, **kwargs)
return use_wsgi_app(your_wsgi_app)
How about this?
class MyController(Controller):
some_controller = use_wsgi_app(your_wsgi_app)
In the former approach, the expose() decorator seems extraneous --
since we're dispatching to a whole app and not just a page, expose
parameters such as "template" don't have any meaning.
(b) Robert Brewer has decided to remove tools.wsgiapp when CherryPy
3.2 comes out (CP ticket #700). He also has a blog post, "Please
don't use wsgiapp" [1], in which he states that the wsgiapp tool "1)
it doesn't conform to the WSGI spec (and cannot be fixed to do so),
and 2) there's a better way to mix content in a CherryPy site:
tree.graft."
His point 1 is half right -- since tools.wsgiapp consumes the response
instead of allowing an iterator to be returned, it doesn't adhere to
PEP 333. However, there's no reason that it couldn't be fixed -- it's
a handler, and handlers can return iterables just fine.
For a long time I thought his second point was simply a matter of
taste, but now I'm coming around to his point of view. If we're
adding another whole app to our site, it's going to come with it's own
set of middleware. Some of that is likely to overlap ours, and some
of ours might not be needed. It'd be better to leave the splitting
of that hair to the developer of the app, not the framework.
Of course, if you don't like that argument against backporting
use_wsgi_app, you should read Robert's blog post. One of his
arguments may sway you if mine doesn't.
(c) In CP3, applications that are added to the tree via graft are pure
WSGI, which means you can't use tools or hooks. The biggest problem
here is that identity requires the visit tool, so using it to secure
the WSGI app isn't possible right now. If course we can rewrite
visit to be WSGI middleware, or migrate to repoze.who/what, but it'd
be better if someone who actually has this itch were to take a shot at
scratching it. I think the community would be better served if I got
back to cleaning up my other tickets & getting the core of TG 1.5 up
to beta quality.
(d) The test cases that I added to #1951 are rather uninteresting.
If we're going to move in a direction that the CherryPy team is
actively discouraging, we need solid tests & use cases.
So right now I'm leaning towards closing 1951 as wontfix, but I'm open
to suggestions.
-Ken
[1] http://www.aminus.org/blogs/index.php/2007/07/24/please_don_t_use_wsgiapp
PS: For the casual reader that just wants to know what mounting a wsgi
app inside of a TG 1.5 site would look like, please see
http://pyamf.org/wiki/CherryPyHowto and
http://www.gordontillman.info/Development/DjangoCherryPy
Christopher Arndt
> I'm struggling with the decision of whether I should backport
> "use_wsgi_app"-type functionality to tg1.1b2,
I think that full wsgi-compliance isn't a key feature of TG 1.1. Florent
told me in a chat that he agrees with this view. So I think it's ok to
move this to te next major release.
> if I should hold off
> until 1.5, or even if it's a mis-feature that shouldn't be backported
> at all.
Point c) certainly seems a strong point in favor of rejecting this as
"wontfix", but would be the alternatives?
Chris
Iain Duncan
>
> I'm struggling with the decision of whether I should backport
> "use_wsgi_app"-type functionality to tg1.1b2, if I should hold off
> until 1.5, or even if it's a mis-feature that shouldn't be backported
> at all.
>
> As a memory refresher, "use_wsgi_app" is a TG 2.0 feature that is used
> to return a WSGI application from an exposed controller, and the
> ticket for backporting it to TG 1.x is #1951. Anyway, here's why I'm
> struggling:
>
> (a) I'm not sure that use_wsgi_app's interface is right. I think it
> would be better if it allowed the WSGI app to be used directly from a
> controller. For example, instead of this:
> class MyController(Controller):
> @expose()
> def some_controller(self, *args, **kwargs)
> return use_wsgi_app(your_wsgi_app)
My two cents are that:
- it would be great to have this in 1.1
- it's more important that the interface be right then for it to come
out sooner
- even though it would be great, it's not worth killing yourself over
for 1.1 as CherrPy 2 is on the way to "legacy"
thanks for listening to the peanut gallery!
Iain
Ken Kuhlman
>
> Ken Kuhlman schrieb:
>> I'm struggling with the decision of whether I should backport
>> "use_wsgi_app"-type functionality to tg1.1b2,
>
> I think that full wsgi-compliance isn't a key feature of TG 1.1. Florent
> told me in a chat that he agrees with this view. So I think it's ok to
> move this to te next major release.
>
I agree completely. The only reason I moved the ticket to 1.1 in the
first place was that it looked simple at the time. I've put it back
to 1.5 now, with a note that it may be closed as wontfix depending on
the outcome of this discussion.
>> if I should hold off
>> until 1.5, or even if it's a mis-feature that shouldn't be backported
>> at all.
>
> Point c) certainly seems a strong point in favor of rejecting this as
> "wontfix", but would be the alternatives?
>
> Chris
>
I don't think I was clear about point c), let me try again. The one
advantage of implementing a tools.wsgiapp-based approach is that you
then can use other CherryPy tools as middleware for the hosted wsgi
application. The patch in question uses this technique, so with it
you could secure a foreign wsgi app with identity as is.
The advantage of using tree.graft instead are more subtle. Robert
Brewer's advocacy for it is mostly based on performance concerns.
Mine is based on the principal of least surprise. Consider the
following controller, which uses the tool-based solution:
class MyRoot(RootController):
@expose()
def index(self):
return 'Hello'
blog = use_wsgi_app(some_wsgi_blog_app)
cherrypy.tree.mount(MyRoot)
Reading this, you would expect that 'blog' would have the same set of
middleware applied to it as 'index', and in fact that would be the
simplest implementation. But that's not always going to be the right
answer since 'some_wsgi_blog_app' is going to come equipped with it's
own set of middleware. For example, it is going to have it's own
mechanism for decoding query parameters, so the NestedVariablesHook is
redundant at best and intrusive at worst.
The tree.mount() syntax for this same setup would be like so:
class MyRoot(RootController):
@expose()
def index(self):
return 'Hello'
cherrypy.tree.mount(MyRoot)
cherrypy.tree.graft(some_wsgi_blog_app, '/blog')
The least surprising thing for this code to do would be for the two
app's middleware to be kept seperate, which is also the safest
behavior. If there is middleware that the developer wants to use in
both portions of the site, they can take advantage of the fact that
cherrypy.tree is itself a wsgi application and just wrap that.
-Ken
Florent Aide
And here I follow both Fumanchu and you. Less surprising and better
performance... this seems to be the way to go (tree.graft). I feel
that this second proposition is more explicit than the first one and
will avoid potential issues with the decoding filters and so on.
As discussed earlier and already changed by you in the ticket, I feel
this should go either in 1.5 or at least in a future 1.1 but not in
this beta.
Florent.