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.
Mmm... strong words.
I don't think anyone is suggesting bare WSGI and Paste for TurboGears.
This isn't how WSGI or Paste is intended to be used.
Comparisons are perhaps a little difficult here, because the layers
don't match up quite right:
Paste
CherryPy
Pylons
TurboGears
That is, CherryPy works on a higher level than Paste, in places closer
to a "real" framework like Pylons; similarly, TurboGears works on a
level that includes a lot more functionality than Pylons. Paste and
CherryPy are not addressing equivalent sets of features. And many of
the things that TG 2.0 is looking for are quite possibly better drawn
from Pylons than Paste -- in that there's ideas in Paste that are
(intentionally) only half-baked, and Pylons more fully exposes them in a
way that could also make sense for TurboGears.
And further, Paste itself is factored into three distinct pieces, most
of which CherryPy includes in its one package; TG is free to cherrypick
(sorry, pun not intended) from Paste's offerings:
* Paste Deploy, the configuration system
* Paste core, the WSGI tools
* Paste Script, the app server (also a file layout generator and other
stuff)
The app server in Paste Script is merely there because I needed
something, I'm not going to argue that it's a wonderful app server; I
think CherryPy's is largely in the same position. The file layout stuff
and other tools in Paste Script don't have equivalents in CherryPy, so
there's no comparison to be made there.
So there's Paste Deploy (the configuration system) and Paste core (a
bunch of WSGI tools).
If TurboGears uses Paste core's WSGI tools or not, it really doesn't
much matter to me. There's lots of useful pieces in there, and I'm
happy to point them out, but you could copy and rename those and tweak
them as you wish and it would be perfectly fine. There's nothing
singular about the implementations in Paste. The argument there is
really about a framework that uses WSGI internally, and one that does
not. Not everything should be squeezed into WSGI -- certainly I've seen
things that seem odd or wrong to me (e.g., wsgiform). It would probably
be easier to debate specific places -- e.g., what is the advantage of
CP's request object over a request object that purely wraps a WSGI
environment (like paste.wsgiwrappers.WSGIRequest)? Or, what is the
advantage of writing authentication using a CherryPy-specific technique
over WSGI middleware?
Configuration is the other big issue. The core of Paste Deploy is
really an interface, not a specific configuration file format. You
could quite reasonably create another config file format, or load
configs from a database or whatever, if you access the same interface
that Paste Deploy accesses.
There's three interfaces that Paste Deploy defines:
paste.app_factory: (global_conf, **local_conf)
paste.filter_app_factory: (app, global_conf, **local_conf)
paste.composite_factory: (loader, global_conf, **local_conf)
All three of these return a WSGI application. "app" is the wrapped WSGI
application. "loader" is an object that can load other apps by name
(used for dispatchers that dispatch to multiple applications).
global_conf is the "inherited" configuration -- configuration that
wasn't specifically intended for this component, but which might provide
useful advise. E.g., you might look for a "debug" global value.
Looking for a global "document_root" value probably isn't very
meaningful, so you are not forced to respect the values in global_conf,
nor are they automatically folded together.
local_conf is restricted, in that the values can all be strings, and
strings should be specially handled. Thus the string 'false' shouldn't
be interpreted as true in a boolean context. It is up to the
application to coerce the values as necessary; no validation of any kind
is part of the interface, except for function signatures.
These three interfaces are how everything is set up in Paste Deploy.
These application/middleware factories are really what defines a "Paste"
application, I suppose -- that is, a configurable object that produces
WSGI applications. You can define these interfaces for code without
including any part of Paste. It is probably possible to provide these
interfaces right now with CherryPy as the application factory (maybe
using something like paste.registry to swap configs if that is indeed a
problem).
It should be noted that configuration is not process-wide in Paste; it
is local to the object returned by the factory. The same application
can be instantiated twice with different configurations, and should
respond properly. It doesn't *have* to of course -- though if it can't,
it should probably raise an exception the second time it is invoked. If
this really is required I'd consider the app/framework to have
"middling" WSGI support, rather than "good" WSGI support (this has long
been a problem with Django, for instance, which has lots of global
process-wide configuration).
Personally I find Paste Deploy's actual configuration to be workable,
but I can certainly imagine other ways to approach the problem. I
believe the interfaces are sufficiently generic that it is possible to
build other configuration systems or other ways to define a website
layout. You can rely on the interfaces Paste Deploy uses to not change,
and as you can see there's no direct bindings to the configuration file
format.
I'm not sure how to compare this to CherryPy's configuration, as I don't
really know what the most core or essential part of CherryPy's
configuration is. Perhaps you could shed light on that.
--
Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
