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

[Tres Seaver]

-----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          tseaver at palladion.com
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-----