[Web-SIG] Proposal for asynchronous WSGI variant

[Manlio Perillo]

Graham Dumpleton ha scritto:
> 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.
> 

Its seems a bit more complex to implement then the start_callable.

Moreover the whole point of removing the start_callable is to simplify 
the writing of middlewares.

With your solution it seems that writing middlewares will not became 
more easy.



> Graham



Manlio Perillo