[Web-SIG] help with the implementation of a WSGI middleware
Phillip J. Eby
pje at telecommunity.com
Tue Jul 8 03:10:31 CEST 2008
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:
>>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
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
> 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.
More information about the Web-SIG