At 04:36 PM 7/7/2008 -0500, Ian Bicking wrote:
Phillip J. Eby wrote:
At 09:58 PM 7/7/2008 +0200, Manlio Perillo wrote:
In this case the first solution is to use this middleware as a
decorator, instead of a full middleware.
This is the correct way to implement non-transparent middleware;
i.e., so-called middleware which is in fact an application API. See:
http://dirtsimple.org/2007/02/wsgi-middleware-considered-harmful.html
for more about this.
Basically, if a piece of middleware has to be there for the
application to run, it's not really "middleware"; it's a misnamed decorator.
In the original WSGI spec, I overestimated the usefulness of adding
extension APIs to the environ... or more likely, I went along with
some of Ian's overenthusiasm for the idea. ;-) Extension APIs in
the environ just mean you have to write your code to handle the
case where the API isn't there -- in which case you might as well
have used a library.
Eh, personally I remain unconvinced. Or, at least, while the
possibility of abuse exists, the extensibility still has many valid
uses, and we're better off with it than with a more object-based
system (e.g., CherryPy hooks, Django middleware, Zope's Acquisition,
and arguably even Zope 3's giant-ball-of-context).
Also, using a *just* library supposes robust and transparent
request-local storage in a manner that works comfortably with the
WSGI call stack, which like any call stack can be recursive and
complex. Lacking such storage, stuffing objects in the environment
is better than the alternatives.
I don't object to stuffing things in the environment; I object to:
1. Putting APIs in there (the API should be regular functions or
objects, thanks)
2. Wrapping middleware around an app to put in APIs that it's going
to have to know about anyway.
Extension APIs really only make sense if they are true *server*
features, not application features; otherwise, you are better off
using a library rather than "middleware" per se.
What server features? Servers are dull.
Which is why there's not much call for extension APIs. :)
Often middleware is used to implement policy separate from the application.
And that kind of middleware is therefore (one hopes) transparent to
the application.
Libraries require another kind of abstraction, and implementing
policy in libraries is, IMHO, messier than the middleware
alternative for many important use cases. Also there exists no
neutral ground for libraries in Python. Maybe egg entry points,
but they aren't all that neutral, and aren't all that applicable
either. zope.interface would like to be neutral ground, but of
course is not. So multiple implementations can at least possibly
congeal around a WSGI request.
Standards for data in the environ may be a good idea. But APIs in
the environ are generally *not* a good idea.
Also of course "server" is a vague term. Request in, response out,
that's the minimal abstraction for HTTP, and there is no "server" in
there. If we're talking about "things that call WSGI applications",
Nope, I mean actual servers.
_______________________________________________
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
