[Web-SIG] help with the implementation of a WSGI middleware

[Phillip J. Eby]

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.