Ian Bicking wrote:
fumanchu wrote:
> Why go through that entire loop when CherryPy is ready now to play the
> part of library Z?
CherryPy is ready now to be a library for using WSGI?
Yes. Although, more importantly, CherryPy is ready now to be a library
for building web applications. Focusing on WSGI misses the forest for
the trees.
> First, I should clarify by repeating that CP _applications_ should not
> "dispatch to a wsgi app". A CP Tree instance might, because that's what
> it's made for. But a CP3 Application instance is just that: a WSGI
> application object and not middleware. There is a wsgiapp Tool in the
> distro, but frankly, I don't recommend it--there are much better ways
> to compose WSGI components. Most of CherryPy makes web application
> development easier, not middleware development. And this is IMO a
> proper focus, because the VAST majority of CP users (and TG users) are
> going to spend the VAST majority of their time writing web apps, not
> WSGI middleware.
No ceilings! We (the larger programming community) is okay at reusing
libraries and certain patterns, but so far not so good at reusing code
that is more complex, in the case of web frameworks, code that has UI
and multiple screens worth of interacting data.
Mounting a subapplication in your application allows you to create
reusable code on this scale (which is hardly a large scale, but
uncommonly large in current practice). This is the scale of reuse that
TurboGears is struggling to achieve, and what can make TurboGears more
than just Another Nice Framework.
Sure; and WSGI middleware is a good place to arrange this mounting,
which is why CherryPy 3 not only allows, but actively encourages and
makes easier the composition of a WSGI stack. CherryPy's Server class
is just as good for managing someone else's HTTP server; CherryPy's
Tree class is just as good for mounting other people's WSGI components,
and you may even decide one of those "subapplications" should be a
CherryPy Application.
>> This is why some sort of stacked, thread-local proxy is needed.
>
> I agree it needs to be thread-local, but it doesn't need to be
> "stacked" unless one *application* (not middleware) truly calls another
> *application*, which isn't AFAICT a use-case of the WSGI spec. In
> addition, CherryPy's expectation is that WSGI middleware should not use
> cherrypy globals, and no CherryPy middleware does.
It's definitely a use case for the WSGI spec. "Application" is just a
role -- one side of the communication plays the part of server, the
other of application. The labels only apply to that communication.
Applications can forward requests to other applications. Much of the
middleware I find myself writing is both middleware and application --
Much? If you're using the term "application" as a "role" then I think
you mean "ALL middleware I find myself writing is both middleware and
application". The mixing of terminology is getting a bit thick. Let me
restate my comment adopting another term from the spec: "pure"
servers/gateways and applications/frameworks (as opposed to middleware,
which plays both sides):
First, I should clarify by repeating that CP _applications_
should not "dispatch to a wsgi app". CP Application objects
are always "pure" WSGI applications. A CP Tree instance
might dispatch, because that's what it's made for; it's middleware.
But a CP3 Application instance is just that: a "pure" WSGI
application object and not middleware. There is a wsgiapp
Tool in the distro, but frankly, I don't recommend it--there
are much better ways to compose a WSGI stack. Most of
CherryPy makes "pure" web application development easier,
not middleware development. And this is IMO a proper focus,
because the VAST majority of CP users (and TG users) are
going to spend the VAST majority of their time writing code on
the far side of a "pure" WSGI application interface, not WSGI
middleware.
> This is why some sort of stacked, thread-local proxy is needed.
I agree it needs to be thread-local, but it doesn't need to
be "stacked" unless one "pure" application (not middleware)
truly calls another "pure" application, which isn't AFAICT a
use-case of the WSGI spec. CherryPy's expectation is that
WSGI middleware should not use cherrypy globals, and no
CherryPy middleware does.
Ian Bicking also wrote:
that is, some but not all requests get forwarded on to another
application, or the dispatch is handled dynamically, or an application
is instantiated based information in the request and then the request is
forwarded to that short-lived application. All these patterns are useful.
No argument there; this is in fact the best use of
middleware--dynamically choosing which WSGI call point to call next.
This is the essence of a WSGI dispatcher, for example, which uses
SCRIPT_NAME + PATH_INFO to make that choice.
Robert Brewer
System Architect
Amor Ministries
[EMAIL PROTECTED]
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TurboGears Trunk" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/turbogears-trunk?hl=en
-~----------~----~----~----~------~----~------~--~---
