[Web-SIG] Proposal for asynchronous WSGI variant

[Graham Dumpleton]

2008/5/7 Manlio Perillo <manlio_perillo at libero.it>:
> 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.

Part of what I was trying to say was that this needn't be exposed to
middlewares, unless it has to be. It was effectively a lower level of
interaction which a middleware immediately on top of the WSGI adapter
would use to hook into the async type model, but then present it to
higher levels as more traditional WSGI interface. That layer would
though obviously use something like greenlets to bridge the two. So, a
way of bringing the control of that bridge into the Python level,
rather than it being interwined and non separable from the underlying
WSGI adapter.

As I said, it was 4am, so probably didn't explain it very well. :-)

Graham