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

Reply via email to