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 : [EMAIL PROTECTED] : http://blog.ianbicking.org
_______________________________________________
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: 
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com

Reply via email to