[Twisted-web] asynchronous WSGI implementation

[ssteinerX@gmail.com]

On Apr 9, 2010, at 7:20 AM, Manlio Perillo wrote:

> Steve Steiner (listsin) ha scritto:

>> Maybe put on BitBucket?  It'd sure be easier to patch/submit pull requests/file tickets on a public repo.
>> 
> 
> I will think about it.
> I don't have experience with BitBucket.  Is the issue tracker good?

It's more than good enough and free.


>>> and I would like to have a *similar* implementation written in pure
>>> Python, for testing purpose.
>> 
>> Will these share, or be able to use, the same demo/test code? 
> 
> Yes.
> 
> The purpose is to have a Twisted and Nginx implementations with the same
> features.

Cool.


>> I'd love to have the option to use Twisted from a WSGI app.  
>> 
> This will be possible with twsgi.
> However please note that I plan to use it for testing purpose only, and
> not in production (at least in the near future).

The Twisted version for testing only, or both versions for testing only?

>> Have you resolved the issues you brought up and have been discussing with PJE over on web-sig?  Which WSGI are you supporting? 
>> 
> I will implement WSGI 1.0.
> 
> Another reason I'm writing twsgi, is that it will be more easy to
> discuss about WSGI issues, having a pure Python implementation.
> 
>> This seems like a different thing than the greenlet/mako thing you were discussing over there.
>> 
> 
> The core is the same.  The WSGI implementation *must* support suspend/resume extension.
> 
> The geenlet middleware will use this extension to implement coroutine
> support over a simple asynchronous WSGI implementation.
> 
> By "simple" I mean that greenlets are not used inside WSGI
> implementation (since greenlets can not be used in my
> ngx_http_wsgi_module, if I'm not wrong).
> 
> greenlets are not required, but without coroutines applications will be
> a mess, due to generator usage.

I guess I'm not real clear on what you're saying here.

>>> By the way: it seems that the WSGI implementation in Twisted Web has
>>> some bugs:
>>> 
>>> * close method of the application iterator is not called in case of
>>> errors
>>> 
>>> * _sendResponseHeaders does not check if start_response has been called
>> 
>> Before someone else says it... please file bugs (helpfully with test cases) at twistedmatrix.com/trac.
>> 
> 
> Of course.
> But before filling a bug report, I wanted a confirmation.

If someone can run the unit-test you provide, it's pretty easy to confirm.

S