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

[Graham Dumpleton]

On 9 April 2010 21:00, Manlio Perillo <manlio_perillo at libero.it> wrote:
> 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.

Please read:

  http://www.wsgi.org/wsgi/Specifications

If a proposal is suggested, it MUST use 'x-wsgiorg.' and not
'wsgiorg.'. Only after it is officially accepted can it use the
'wsgiorg.'.

I would question whether you should even be using 'x-wsgiorg.' as as
far as I can see from my quick scans of emails, you aren't even
supporting WSGI proper as you are dropping support for bits. As such,
it isn't WSGI, only WSGIish so how can you justify using the name.

Why don't you given it all a completely different name else you will
just cause ongoing confusion like you did with when you felt you could
reuse the 'mod_wsgi' name for your nginx version even though I asked
you to use a different name. It has been an absolute pain seeing
discussions on places like #django irc where people don't know when
people mention mod_wsgi whether they are talking about Apache of
nginx.

Graham

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