[Web-SIG] help with the implementation of a WSGI middleware
ianb at colorstudy.com
Mon Jul 7 23:36:32 CEST 2008
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:
> 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
> 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.
Often middleware is used to implement policy separate from 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.
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",
well I have a ton of those that never use sockets and you'd be hard
pressed to classify them as "servers".
Ian Bicking : ianb at colorstudy.com : http://blog.ianbicking.org
More information about the Web-SIG