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

[Ian Bicking]

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.

> 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