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.
_______________________________________________
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
