[Web-SIG] PEP 444 / WSGI 2 Async

[Alice Bevan–McGregor]

On 2011-01-06 09:06:10 -0800, 
chris.dent at gmail.com said:
> I wasn't actually talking about the log dump. That was useful. What I 
> was talking about were earlier messages in the thread where people were 
> making responses, quoting vast swaths of text for no clear reason.

Ah.  :)  I do make an effort to trim quoted text to only the relevant parts.

> On Thu, 6 Jan 2011, Alice Bevan–McGregor wrote:
>> 	https://github.com/GothAlice/wsgi2/blob/master/pep444.textile
> 
> Thanks, watching that now.

The textile document will no longer be updated; the pep-444.rst 
document is where it'll be at.

> I should have been more explicit here as I now feel I must defend 
> myself from frowns. I'm not talking about single methods that do the 
> entire app. I nest a series of middleware that bottom out at Selector 
> which then does url based dispatch to applications, which themselves 
> are defined as handlers (simple wsgi functions) and access 
> StorageInterfaces and Serializations. The middleware, handlers, stores 
> and serializers are all independently testable (and usable).

*nods* My framework (WebCore) is basically a packaged up version of a 
custom middleware stack so I can easily re-use it from project to 
project.  I assumed (in my head) you were "rolling your own" 
framework/stack.

>> That is already the case with filters, and will be when I ratify the 
>> async idea (after further discussion here).  My current thought process 
>> is that async will be optional for server implementors and will be 
>> easily detectable by applications and middleware and have zero impact 
>> on middleware/applications if disabled (by configuration) or missing.
> 
> This notion of being detectable seems weird to me. Are we actually 
> expecting an application to query the server, find out it is not async 
> capable, and choose a different code path as a result? Seems much more
> likely that the installer will choose a server or app that meets their 
> needs. That is: you don't need to detect, you need to know (presumably 
> at install/config time).
> 
> Or maybe I am imagining the use cases incorrectly here. I think of app 
> being async as an explicit choice made by the builder to achieve some 
> goal.

More to the point it needs to be detectable by middleware without 
explicitly configuring every layer of middleware, potentially with 
differing configuration mechanics and semantics.  (I.e. arguments like 
enable_async, async_enable, iLoveAsync, ...)

>>> I can't get my head around filters yet.[snip]
>> 
>> Filters offer several benefits, some of which are mild:
>> 
>> :: Simplified application / middleware debugging via smaller stack.
>> :: Clearly defined tasks; ingress = altering the environ / input, 
>> egress = > altering the output.
>> :: Egress filters are not executed if an unhandled exception is raised.
> 
> Taken individually none of these seem super critical to me.
> 
> Or to put it another way: Yeah, so?
> 
> (This is the aforementioned resistance showing through. The above 
> sounds perfectly nice, reasonable and desireable, but not _necessary_.)

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

>> Filters are optional, and an example is/will be provided for utilizing 
>> > ingress/egress filter stacks as middleware.
> 
> In a conversation with some people about the Atom Publishing Protocol I 
> tried to convince them that the terms SHOULD and MAY had no place in a 
> spec. WSGI* is not really the same kind of spec, but optionality
> still grates in the same way.

I fully agree; that's why a lot of the PEP 333 "optionally" or "may" 
features have become "must".  "Optionally" and "may" simply never get 
implemented.

Filters are optional because a number of people have raised valid 
arguments that it might not be entirely needed.  Thus, it's not 
required.  But I strongly feel that some defined API should be present 
in (or /at least/ referred to by) the PEP, otherwise the future will 
hold the same server-specific incompatible implementations.

	- Alice.