Re: asynchronous WSGI implementation

On 10:32 am, [email protected] wrote:
>Hi.
>
>I have started to write an asynchronous WSGI implementation for
>Twisted Web.
>
>The code is available from a Mercurial repository:
>http://hg.mperillo.ath.cx/twisted/twsgi/
>
>The WSGI application is executed in the main Twisted thread, and the
>application will be able to directly use Twisted features.
>
>The reason I'm doing this is because I have written a WSGI
>implementation for Nginx:
>http://hg.mperillo.ath.cx/nginx/ngx_http_wsgi_module
>
>and I would like to have a *similar* implementation written in pure
>Python, for testing purpose.
>
>
>I have some questions:
>
>* What's the use of
>
>     __metaclass__ = type
>
>   in twisted.web.wsgi ?

This makes all classes without a base class defined in the module new- 
style.
>* Is request.content always buffered (in memory or temporary file)?

It's always buffered, in memory if it is small, in a temporary file if 
it is large (same rules as for a normal request in Twisted Web).  Once 
#288 is resolved, it will probably make sense to stream the request body 
instead.
>* In my ngx_http_wsgi_module, when the yielded string can not be sent 
>to
>  the client (because OS buffer is full), I suspend the execution of the
>  application, and resume it when the socket is ready.
>
>  I want to do the same with Twisted, and the way to go is to be a
>  push producer.
>
>  However I don't know how to implement and use the IPushProducer
>  interface for _WSGIResponse.

The request object has a register producer method.  What else are you 
having trouble with?
>
>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

This looks like a bug that should be fixed.
>* _sendResponseHeaders does not check if start_response has been called

What are the practical consequences of this?

Jean-Paul