Alice Bevan–McGregor wrote:
> [email protected] said:
> > I can't get my head around filters yet...
>
> It isn't necessary; it is, however, an often re-implemented feature of
> a framework on top of WSGI. CherryPy, Paste, Django, etc. all
> implement some form of non-WSGI (or, hell, Paste uses WSGI middleware)
> thing they call a 'filter'.
Or, if you had actually read what I wrote weeks ago, you'd say "CherryPy used
to have a thing they call a 'filter', but then replaced it with a much better
mechanism ("hooks and tools") once the naïve categories of ingress/egress were
shown in practice to be inadequate." Not to mention that, even when CherryPy
had something called a 'filter', that it not only predated WSGI but ran at the
innermost WSGI layer, not the outermost. It's apples and oranges at best, or
reinventing the square wheel at worst.
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.
Robert Brewer
[email protected]
_______________________________________________
Web-SIG mailing list
[email protected]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
