| Newsgroups |
gmane.comp.python.twisted.web |
| Message-ID |
<[email protected]> |
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