[Web-SIG] PEP 444 / WSGI 2 Async

[Robert Brewer]

Alice Bevan–McGregor wrote:
> chris.dent at gmail.com 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
fumanchu at aminus.org