[Web-SIG] WSGI Middleware Dependancy Graphing (was: PEP 444 / WSGI 2 Async)

[Alice Bevan–McGregor]

On 2011-01-06 13:08:04 -0800, Robert Brewer said:

> Or, if you had actually read what I wrote weeks ago...

I did.  Apologies for forgetting the detail of the implementation being 
deprecated.

> We don't need Yet Another Way of hooking in processing components; if 
> anything, we need a standard mechanism to compose existing middleware 
> graphs so that invariant orderings are explicit and guaranteed. For 
> example, "encode, then gzip, then cache". By introducing egress filters 
> as described in PEP 444 (which mentions gzip as a candidate for an 
> egress filter), you're then stuck in a tug-of-war as to whether to 
> build a new caching component as middleware, as an egress filter, or 
> (most likely, in order to compete) both.

I do, in fact, have a proposal for declaring dependancies, however such 
declaration is utterly useless unless differing middleware-based 
implementations (e.g. sessions) can agree on a common API for their 
feature sets.  I feel strongly that this idea does not belong in PEP 
444; it's one of the few things I think should be its own PEP.

My mechanism (for which I do have a working implementation against WSGI 
1; my web framework uses it) involves middleware layers declaring 
several attributes on themselves:

provides - abstract API names
uses - ordering hint, no dependancy
needs - die if dependancy is not met
before - explicit ordering, including "*"
after - explicit ordering, including "*"

For this to really work, however, it'd also need either an 
entrypoint-based way of looking up components (making the graph truly 
dynamic), or it needs to be combined with explicit packages a la 
setuptools.require.  In that instance, you've already done the ordering 
yourself, so dependancy graphing is moot.

	- Alice.