[Web-SIG] Proposal for asynchronous WSGI variant

[Graham Dumpleton]

2008/5/7 Christopher Stawarz <cstawarz at csail.mit.edu>:
> On May 5, 2008, at 10:08 PM, Graham Dumpleton wrote:
>
>
> > If write() isn't to be returned by start_response(), then do away with
> > start_response() if possible as per discussions for WSGI 2.0.
>
>  I think start_response() is necessary, because the application may need to
> yield for I/O readiness (e.g. to read the request body, as in my example
> app) before it decides what response status and headers to send.

One could come up with other ways of doing it which aligns better with
WSGI 2.0. I previously gave an idea as a starting point for
discussion, but don't think others really understood what I was
suggesting. But then I did post it at 4am in the morning in the middle
of a baby induced period of sleep deprivation. See post 24 in:

http://groups.google.com/group/python-web-sig/tree/browse_frm/thread/74c1f8cf15adf114/d98086a8db568ebd?rnum=24

I think what was missed by others was that I wasn't suggest that the
102 code be sent all the way back to the client, but as a convention
between WSGI application and underlying WSGI adapter only, to
facilitate the ability to return control back to the WSGI adapter
before one had decided what actual response headers to send. This
seems to align with what you want.

Graham