[Web-SIG] [ANN] twsgi: asynchronous WSGI implementation for Twisted Web

[Manlio Perillo]

I have started to write an asynchronous WSGI implementation for Twisted Web.

The standard implementation execute the WSGI application in a separate
thread.
twsgi will instead execute the application in the main Twisted thread.

The advantage is that twsgi is better integrated in Twisted, and WSGI
applications will be able to use all features available in Twisted.


Code is availale from a Mercurial repository:
http://hg.mperillo.ath.cx/twisted/twsgi


The purpose of twsgi is to have a pure Python implementation of WSGI
with support for asynchronous HTTP servers and asynchronous WSGI
applications.

The implementation is similar to ngx_http_wsgi_module, and can be used
to quick test asynchronous extensions.

write callable is not implemented (calling it will raise NotImplemented
error), since write callable can not be implemented in an asynchronous
web server without using threads (and twsgi *does* not use threads).

ngx_http_wsgi_module does the same.


TODO
----

* support for suspending iteration over WSGI app iter, when socket is
  not ready to send data.
  execution will be resumed when socked is ready again.

* support for suspend/resume extension, as described here:
  http://comments.gmane.org/gmane.comp.python.twisted.web/632

  It will have some differences:

    - the name will be 'wsgiorg.suspend' instead of 'wsgi.pause_output'

      The wsgiorg namespace is used, since the plan is to have it
      standardized [1], but it can only be implemented on asynchronous
      servers.

    - wsgi.pause_output function will accept an optional timeout, in
      milliseconds.

      If timeout is specified, application will be implicitly resumed
      when timeout expires.

    - resume function will return a boolean value.
      True: if execution was suspended and it is going to be resumed
      False: if execution was not suspended

      The return value can be used to check if timeout specified in
      wsgiorg.suspend expired.

      I'm not sure if a boolean value is the best solution.
      Maybe it should return -1 is execution was not suspended, and 0
      otherwise.


[1] unlike other proposed async extensions, suspend/resume is much more
    simple and easy to implement, so it is more likely to have a wide
    consensus over the specification.


Feedbacks are welcomed.


Regards  Manlio