[Web-SIG] PEP 444 / WSGI 2 Async

[chris.dent at gmail.com]

On Thu, 6 Jan 2011, Alice Bevan–McGregor wrote:

> Yeah; I knew the IRC log dump was only so useful.  It's a lot of material to 
> go through, and much of it was discussed at strange hours with little sleep. 
> ;)

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.

> 	https://github.com/GothAlice/wsgi2/blob/master/pep444.textile

Thanks, watching that now.

>> I don't use frameworks, or webob or any of that stuff. I just cook up 
>> callables that take environ and start_response. I don't want my awareness 
>> of the basics of HTTP abstracted away, because I want to make
>> sure that my apps behave well.
>
> Kudos!  That approach is heavily frowned upon in the #python IRC channel, but 
> I fully agree that working solutions can be reasonably made using that 
> methedology.  There are some details that are made easier by frameworks, 
> though.  Testing benefits from MVC: you can test the dict return value of the 
> controller, the templates, and the model all separately.

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

I find the MVC language ineffective when thinking about the HTTP
verbs and the resources the app(s) present(s). In fact I think it
encourages _bad_ thinking.

Anyway, the point of the methodolgy is, that from the perspective of
the web data, the entry and exit points are unadulterated WSGI.

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

>> 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_.)

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

> The problem with /not/ including the filtering API (which, by itself is 
> stupidly simple and would barely warrant its own PEP, IMHO) is that a 
> separate standard would not be seen and taken into consideration when 
> developers are writing what they will think /must/ be middleware.

Yeah, so? :)

> See my post from a few minutes ago which covers this.

Yay!

-- 
Chris Dent                                   http://burningchrome.com/
                                  [...]