-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ian Bicking wrote: > 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.
I have occasionally left repoze.tm out of the stack in front of an application which would normally be configured to use it, precisely to guarantee that no transactions can be implicitly committed: I think this is a perfect case of "transparent" middleware: - The application uses the 'transaction' library (if desired) to annotate transactions, and to register "dirty" objects; note that the library will silently start a thread-local transaction if one is not already present. - The middleware, if present, begins a transaction on entry, then commits the transaction on non-exceptional exit, or aborts it on exceptional exit. - The application doesn't need to change at all if the middleware is absent. It doesn't use or expect any API to be jammed into the WSGI environment at all. > 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. As long as the application does the Right Thing if it is missing (raising Unauthroized, or whatever), any middleware to set that variable is purely optional. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIdspY+gerLs4ltQ4RAoofAKCTIHPfnfDjuOrVkTgvvKB1nmndygCfT4C1 Wvs9oj5YLR5uv4NCsKbYrRk= =9udz -----END PGP SIGNATURE----- _______________________________________________ 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
