Hi Robert,
fumanchu wrote:
More discussion to follow. I just spent a man-year of work making CP 3
do all this and more and be beautiful at the same time, and I'll be
damned if I let TG devolve back to preferring the ugliness of bare
WSGI
and Paste.
First of all I'd like to say that CP3 does really looks beautiful and
that it's wsgiserver is really good. Whatever TG 2.0 becomes it will
surely use it's server by default.
As I've mentioned, the only problem I've seen when experimenting with
it is how it handles module globals because of the way I'd like to
build the WSGI stack for the application. I know that CherryPy can
already build a tree composed of CP and wsgi apps, however, from what
I've seen (I hope I'm wrong but I believe I'm not) it seems to me
that CherryPy wants to be the only one building the stack.
What I mean with this is that by the way I've seen a CP app is
mounted and the server started, the whole tree is built by CP
mechanisms, mounted under a given prefix and served. This is what
the quickstart function looks like:
def quickstart(root, script_name="", config=None):
"""Mount the given app, start the engine and builtin server,
then block."""
if config:
cherrypy.config.update(config)
cherrypy.tree.mount(root, script_name, config)
cherrypy.server.quickstart()
cherrypy.engine.start()
CP and wsgi apps are mounted or grafted into a global cherrypy.tree,
and then a global server and a global engine are started.
However, I'd like to use Paste Deploy for deployment of TG apps. This
is for many reasons, most importantly:
* it looks like it's powerful enough for our needs (composing apps,
applying filters, configuring a server (even CP), etc...) I know CP3
can already do this, but, read on...
* It's not tied to any particular framework. Pylons is using it and
it looks like any wsgi compliant framework/app could use it too (just
implement it's interface and provide entry points... could even be
done by a user wanting to integrate a non "paste-enabled" wsgi app
into it's workflow).
The last point I believe to be very important because I'd like to see
other framework's apps easy to deploy along TG apps and the opposite
way around too, TG apps being easy to deploy along other frameworks'
apps.
I'd like to stress the fact that this deployment should be easy and
as standardized as possible for the end user too (sysadmins, etc..),
not only developers.
To achieve this it looks obvious to me that we (wsgi frameworks)
shall agree on a "standard", framework-independent interface and
paste deploy's is the only one I know of (is there any other?)
So I began experimenting and I got to this paste.app_factory
implementation for deploying a CP3 app: http://paste.turbogears.org/
paste/769. cputils looks like this: http://paste.turbogears.org/paste/
770.
What I'm trying to achieve with this are self contained CP apps (with
their own tree, config, etc...) which can be mounted by a
paste.URLMap (or any other composite app factory) at *any* point in
the tree.
However, I haven't found easy to isolate each CP app because of the
mentioned use of globals. cherrypy.config is easy to monkey patch to
be app specific. cherrypy.request and reponse too. I know they're
already thread-local, but what if a CP app dispatches (in the same
thread) to a wsgi app that turns out to be another CP app wrapped
into an opaque WSGI app?, would they get app-specific cp globals? To
put it in other words:
_tree = Tree()
# mount stuff
# global tree
cherrypy.tree.graft(_tree, '/foo')
cherrypy.tree.graft(another_app, '/bar')
and a little diagram:
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
Would CP controllers under _tree see a different cp.config,
cp.request, cp.response, etc... than those under cp.tree? This is why
some sort of stacked, thread-local proxy is needed.
So it seems to me that if TG wants to use CP3's engine and use
paste.deploy's interfaces some patching or monkey-patching is
needed... I'm really not very comfortable with this sort of monkey-
patching because we seem to be poking too many CP internals again.
Experience with 1.0 has taught us that this leads to a hard time if
we want to migrate to newer CP versions.
Another thing I'd like to see in TG is the use of middleware instead
of CP3 tools and hooks. I've got nothing against them and I'm sure
their design is sound and powerful. However, TG 2.0 want's to build
on independent components which can be stolen, adapted or written
from scratch and be reused in other frameworks/apps so it looks like
WSGI middleware is a better alternative to CP's tools/hooks because
the later can only be used in CP apps.
This brings us to a point that we should consider what CP3 provides
us with. If we don't need config, deployment, tools and filters we're
left with the server and it's dispatching mechanisms which is what
most TG users are used to and love.
Taken all this into account I believe it's less risky to use CP3
server and emulate CP3's dispatching rather than heavily monkey-
patching CP3's internals.
Opinions?
Regards,
Alberto
