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
