[Web-SIG] WSGI and start_response

[Manlio Perillo]

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
>>   middlewares
>> - 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
  subrequests.
  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:
  http://comments.gmane.org/gmane.comp.python.twisted.web/632

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

  The suspend/resume extension allows an application to explicitly
  suspend/resume execution, so it is a nice complement for an
  asynchronous server.

  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.

> Under
> WSGI 1, you can do this by yielding empty strings before calling
> start_response.  

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

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

Right.

My previous attempt was a failure, since the extensions have severe
usability problem.

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

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


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


Thanks  Manlio