[Web-SIG] PEP 444 / WSGI 2 Async

[Alice Bevan–McGregor]

Chris,

On 2011-01-06 05:03:15 -0800, Chris Dent said:
> On Wed, 5 Jan 2011, Alice Bevan–McGregor wrote:
>> This should give a fairly comprehensive explanation of the rationale 
>> behind > some decisions in the rewrite; a version of these 
>> conversations (in narrative > style vs. discussion) will be added to 
>> the rewrite Real Soon Now™ under the > Rationale section.
> 
> Thanks for this. I've been trying to follow along with this 
> conversation as an interested WSGI app developer and admit that much of 
> the thrust of things is getting lost in the details and people's 
> tendency to overquote.

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

> One thing that would be useful is if, when you post, Alice, you could 
> give the URL of whatever and wherever your current draft is.

Tomorrow (ack, today!) I'll finish converting over the PEP from Textile 
to ReStructuredText and get it re-submitted to the Python website.

	https://github.com/GothAlice/wsgi2/blob/master/pep444.textile
	http://www.python.org/dev/peps/pep-0444/

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

> Plain WSGI is a good thing, for me, because it means that my 
> applications are a) very webby (in the stateless HTTP sense) and b) 
> very testable.

c) And very portable.  You need not depend on some pre-arranged stack 
(including web server).

> I agree with some others who have suggested that maybe async should be 
> its own thing, rather than integrated into a WSGI2. A server could 
> choose to be WSGI2 compliant or AWSGI compliant, or both.

-1

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.

> That said I can understand why an app author might like to be able to 
> read or write in an async way, and being able to shelf an app to wait 
> around for the next cycle would be a good thing.

Using futures, async covers any callable at all; you can queue up a 
dozen DB calls at the top of your application, then (within a body 
generator) yield those futures to be paused pending the data.  That 
would, as an example, allow complex pages to be generated and streamed 
to the end-user in a efficient way -- the user would see a page begin 
to appear, and the browser downloading static resources, while 
intensive tasks complete.

> I just don't want efforts to make that possible to make writing a 
> boring wsgi thing more
> annoying.

+9001

See above.

> I can't get my head around filters yet. They sound like a different way 
> to do middleware, with a justification of something along the lines of 
> "I don't like middleware for filtering". I'd like to be (directly) 
> pointed at a more robust justification. I suspect you have already 
> pointed at such a thing, but it is lost in the sands of time...

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.

The latter point is important; you do not want badly written middleware 
to absorb exceptions that should bubble, etc.  (I'll need to elaborate 
on this and add a few more points when I get some sleep.)

> Filters seem like something that could be added via a standardized 
> piece of middleware, rather than being part of the spec. I like minimal 
> specs.

Filters are optional, and an example is/will be provided for utilizing 
ingress/egress filter stacks as middleware.

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.  
Seing as a middleware version of a filter is trivial to create (just 
execute the filter in a thin middleware wrapper), it should be a 
consideration up front.

>> Latin1 = \u0000 → \u00FF [snip]
> 
> There's a rule of thumb about constraints. If you must constrain, do 
> none, one or all, never some. Ah, here it is: 
> http://en.wikipedia.org/wiki/Zero_One_Infinity
> 
> Does that apply here? It seems you either allow unicode strings or you 
> don't, not a certain subsection.

+1

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

> That's all I got so far. I applaud you for taking on this challenge. 
> It's work that needs to be done. I hope to be able to comment more and 
> make a close reading of the various documents, but time is tough 
> sometimes. I'll do what I can as I can.

Thank you, and I look forward to additional input!

	- Alice.