fumanchu wrote:
* 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).
Despite the rhetoric, frameworks are not evil per se; they provide a
common interface to all components and are crucial for performing
expensive operations _once_. WSGI does provide a
lowest-common-denominator interface, but few people want to program to
the WSGI interface all day long. So alternatives (like CherryPy, or
paste.wsgiwrappers) are recommended to make working with WSGI more
pleasant.
paste.wsgiwrappers is a way of helping people use the WSGI interface; it
isn't an alternative to that interface. It is very much constrained to
what WSGI allows, and I've gone out of my way to keep it that way.
But there's a vicious circle which accompanies the desire to
"not have a framework":
1. You build your initial offering using middleware from project A.
2. The developers of project A find that parsing headers, params, and
various calculated data is slow, so they cache behind the scenes in
library Z.
Headers are already parsed. The query string must be parsed, and
possibly the request body. I'm not sure what else really needs to be
parsed.
3. The holy grail of WSGI middleware is that we should be able to
steal code from lots of different projects, so you add another bit of
WSGI middleware from project B.
4. The developers of project B find that parsing headers, params, and
various calculated data is slow, so they cache behind the scenes in
library Y.
5. As the number of libraries Z, Y, X... increases, the number of
times the same data is parsed rises (increasing CPU time) and ALSO the
number of places it is cached (increasing memory footprint).
This seems like you're looking for a problem that does not yet exist,
and may never exist. So long as the results are semantically correct,
the overhead (memory or CPU) that you are referring to is not that
large, and dependent on the software stack.
Nevertheless, I'm already in the progress of addressing this. The ad
hoc solution that Paste has used is described here:
http://wsgi.org/wsgi/Specifications/handling_post_forms -- but I
withdrew that as a specification as I'm working on a library to handle
the case more generally, in HTTPEncode
(http://svn.pythonpaste.org/Paste/HTTPEncode/trunk) and WSGIFilter
(http://svn.pythonpaste.org/Paste/WSGIFilter/trunk). Once I'm more
comfortable with that I'll probably try to write it up as a
specification again.
6. Turbogears finds this state of affairs unacceptable, and decrees,
"we will only support middleware built with library Z (or no library)".
Performance concerns do not require any kind of restriction like that,
they only lead people to advise certain combinations. As long as other
combinations *work*, there's no reason to restrict people's choices. As
long as everyone obeys WSGI (and doesn't try to pass information through
non-WSGI channels) then they *will* work together.
7. Library Z therefore plays the role of a framework, no matter how
much "proof by repeated assertion" that it is "not a framework" floats
around in its marketing.
It's not a framework, just the basis of a well-performing stack that
TurboGears uses and recommends.
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?
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?)
That goal should be addressed on web-sig, I think. Choosing a current
implementation (of any portion of a web stack) and expecting each web
tool to declare it a "standard" has a pretty poor track record in the
world of Python web apps. The WSGI standard, by contrast, was hashed
out on web-sig for quite some time, taking input from all possible
players in that space.
I brought up the possibility on Web-SIG of standardizing on something
based on these interfaces, but no one seemed interested in it. Mostly
Luke Arno was the most interested in stuff, and he prefers constructing
stacks in Python so a standard interface didn't mean much to him.
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?
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.
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 --
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.
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.
I don't think you should use paste.deploy's interfaces. They're not a
standard yet by any stretch of the imagination, and I've written
extensively on why CherryPy's deployment interface is better at
http://www.cherrypy.org/wiki/CherryPyAndPaste.
I think I'll have to write a full retort to that comparison, because
there's just too much in there to go over it here.
As far as configuration, I'm not really clear on your argument. It
doesn't look substantially different to me, except that the only way to
configure dispatchers in CP (like Paste's URLMap or CP's Tree) is
through ad hoc code.
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 latter
can only be used in CP apps.
This is a non-sequitur. Nothing about CP keeps you from *using* WSGI
components from anywhere, whether stolen, adapted or written from
scratch. Please, beg, borrow and steal good code from these sources.
But at the end of the day, middleware cannot implement all
functionality (and I would argue little of the interesting
functionality) for extending the request/response process. So you'll
need some code to allow plugins inside the application itself, after
all the WSGI layers have done their thing. CherryPy is ready, willing,
and able to provide that extension system today. Why reinvent it?
AFAICT TurboGears has its own heavy use of decorators for some plugins,
normal library code of course, the toolbox and other extensions, and
lots of other stuff. They know their way around plugins.
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.
There's something missing from the above list: management. You are
going to end up reinventing the entire set of management layers, like
CherryPy's Server class (which governs the HTTP server, and can now
start/stop/manage multiple HTTP servers), the Engine class (which
governs the OS process)
Paste Script has some of this, but I personally find supervisor2 much
more robust so I don't plan to pursue this direction further inside Paste.
and the Toolbox (which provides a plugin
architecture). You do need Tools in some form, as I've argued above.
You might decide that you want more of CherryPy's builtin tools to be
implemented as middleware, which is fine. Whether you used CP or not,
you'd have to supply those.
But CP already has solid, tested, versions of these features that
already exist, and they are manageable in code, by code, like any good
component-management and plugin architecture. Why reinvent all that? My
guess is that, using a single page of CherryPy 3 code, TG could provide
an admin webapp which allowed a new developer to compose apps,
middleware, and tools into a complete web stack without ever taking the
server down. This is possible because the arrangement of components in
CherryPy 3 is done using objects, not config-file entries (although you
may use config files to declare those objects).
As I've shown, the Paste Deploy interfaces are simple callables, and
entirely manipulable programmatically, in entirely obvious ways.
I put a LOT of work into CherryPy 3 making sure that, at every possible
point where TG has or might monkeypatch CP, there is a beautiful object
or attribute which is designed to be replaced with a subclass or other
delegate to meet your needs. Since Paste provides neither application
management nor application extension tools, TG will have to rewrite
those. Why do so when CherryPy already has proven solutions in this
space?
I'm not really sure what specific tools you are referring to. Certainly
Paste doesn't include everything; but it has lots of stuff in it, and
there are several complementary packages, and developers using WSGI
tools who would be interested in collaborating with TurboGears
developers. I don't think writing the code is the hard part here, it's
writing the system that's hard. We're very focused on the system, on
the site, on how it all works together -- possibly more focused on that
than on the writing of individual applications.
--
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
-~----------~----~----~----~------~----~------~--~---
