[Web-SIG] help with the implementation of a WSGI middleware
ianb at colorstudy.com
Tue Jul 8 04:42:24 CEST 2008
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
> And that kind of middleware is therefore (one hopes) transparent to the
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
Ian Bicking : ianb at colorstudy.com : http://blog.ianbicking.org
More information about the Web-SIG