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

[Ian Bicking]

Phillip J. Eby wrote:
> 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.

Well, sometimes this occurs because you want the middleware at a 
different level.  E.g., something like the transaction handler in 
repoze.tm (http://svn.repoze.org/repoze.tm/trunk/) -- you expect it to 
be there, and for it to put an object with a certain API in the 
environment, and it implements an outer transaction boundary.  It's 
something you can put in fairly speculatively, so that some consumer can 
make use of it.  It's also a case where objects seemingly well outside 
the scope of the controller/web need access to some transaction manager, 
and that manager's most obvious scope is for the request, and so some 
common means to "get the current transaction manager" would be nice. 
Anyway, arguably a good example of both an API in the environment, and 
an API that would be nice if you could easily access without being bound 
to any particular framework's convention for how to get the current request.

>> Often middleware is used to implement policy separate from the 
>> application.
> 
> And that kind of middleware is therefore (one hopes) transparent to the 
> application.

Often *some* implementation must be present.  E.g., if you check 
REMOTE_USER you implicitly expect *something* to set REMOTE_USER.

>>   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.

Yes, generally I agree.

>> 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.

Well, as I was implying, anything that calls an app is in some sense a 
server.

-- 
Ian Bicking : ianb at colorstudy.com : http://blog.ianbicking.org