WSGI support (was [Twisted-web] Re: status of Twisted Web and Web 2)

[David Reid]

On Mar 6, 2008, at 2:00 AM, Manlio Perillo wrote:
> Maybe it can be of interest my work on adding asynchronous support  
> in WSGI.
>
> I'm developing a WSGI module for the Nginx web server:
> http://hg.mperillo.ath.cx/nginx/mod_wsgi/
>
> The great advantage of Nginx over Twisted is it's support for  
> multiple worker processes; this helps a lot with application  
> "reloading" and for better support of I/O bound applications.

I'm not quite convinced that the concurrency model of the container is  
the real bottleneck in WSGI applications as opposed to it's  
synchronous API.
A Twisted WSGI container could use a process pool just as easily as a  
thread pool, but you're still taking a properly asynchronous container  
and letting it run an application that will block for a long period of  
time.

> I think that having a "pure" asynchronous WSGI implementation in  
> Twisted Web that implements this extension can be a good starting  
> point for trying to standardize asynchronous web applications.
>
>
> P.S.: the wsgi.pause_output extension, proposed some years ago here  
> by Donovan Preston should be very easy to implement using ngx.poll,  
> and a pipe.

Does anyone support said extension?  Does everyone support the same  
pause_output? Or just functions of the same name?

It shouldn't be very hard to add support for it to Twisted.web2's WSGI  
implementation either, but I don't much see the point if no one else  
supports it.  I'm not convinced that WSGI is at all a useful means of  
writing asynchronous web applications.  I think WSGI's only benefit is  
that it allows you to almost write your application code once and run  
it on multiple containers.

-David

"Usually the protocol is this: I appoint someone for a task,
which they are not qualified to do.  Then, they have to fight
a bear if they don't want to do it." -- Glyph Lefkowitz