[Web-SIG] WSGI and start_response
manlio_perillo at libero.it
Thu Apr 8 20:06:17 CEST 2010
P.J. Eby ha scritto:
> At 05:40 PM 4/8/2010 +0200, Manlio Perillo wrote:
>> With WSGI 2.0 we will end up with:
>> - WSGI 1.0, a full featured protocol, but with hard to implement
>> - WSGI 2.0, a simple protocol, with more easy to implement middlewares
>> but without support for some "advanced" applications
> Let me see if I understand what you're saying. You want to support
> suspending an application, without using greenlets or threads.
What I'm trying to do is:
* as in the example I posted, turn Mako render function in a generator.
The reason is that I would lite to to implement support for Nginx
During a subrequest, the generated response body is sent directly to
the client, so it is necessary to be able to flush the Mako buffer
* implement the simple suspend/resume extension, as described here:
Note that my ngx_http_wsgi_module already support asynchronous web
server, since when the application returns a generator and sending a
yielded buffer to the client would block, execution of WSGI
application is suspended, and resumed when the socket is ready to send
The suspend/resume extension allows an application to explicitly
suspend/resume execution, so it is a nice complement for an
I would like to propose this extension for wsgiorg namespace.
Not that, however, greenlets are still required, since it will make the
code much more usable.
> WSGI 1, you can do this by yielding empty strings before calling
No, in this case this is not what I need to do.
I need to call start_response, since the greenlet middleware will yield
data to the caller before the application returns.
> Under WSGI 2, you can only do this by directly
> suspending execution, e.g. via greenlet or eventlets or some similar API
> provided by the server. Is this your objection?
In WSGI 2 what I want to do is not really possible.
The reason is that I don't use greenlets in the C module (I'm not even
sure greenlets can be used in my ngx_http_wsgi module)
Execution is suspended using the "normal" suspend extension.
The problem is with the greenlet middleware that will force a different
> As far as I know, nobody has actually implemented an async app facility
> for WSGI 1, although it sounds like perhaps you're trying to design or
> implement such a thing now.
My previous attempt was a failure, since the extensions have severe
It is the same problem you have with Twisted deferred. In this case
every function that call a function that use the async extension must be
In my new attempt I plan to:
1) Implement the simple suspend/resume extension
2) Implement a Python extension module that wraps the Nginx events
3) Implement a pure Python WSGI middleware that, using greenlets, will
enable normal applications to take advantage of Nginx async features.
This middleware will have the same purpose as the Hub available in
> If so, then there's nothing stopping you
> from implementing a WSGI 1 server and providing a WSGI 2 adapter, since
> as you point out, WSGI 2 is easier to implement on top of WSGI 1 than
> the other way around.
Yes, this is what I would like to do.
Do you think it will possible to implement all the requirements of WSGI
2 (including Python 3.x support) in a simple adapter on top of WSGI 1.0 ?
And what about applications that need to use the WSGI 1.0 API but
require to run with Python 3.x?
More information about the Web-SIG