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 _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
