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

Manlio Perillo manlio_perillo at libero.it
Thu Mar 6 14:06:52 EST 2008


Phil Christensen ha scritto:
> On Mar 6, 2008, at 10:56 AM, David Reid wrote:
>> On Mar 6, 2008, at 2:00 AM, Manlio Perillo wrote:
>>> 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.
> 
> I'd have to disagree (slightly). There's nothing about WSGI that makes 
> it only applicable to one approach or another (that is, synchronous 
> versus asynchronous). 

Right.
This is what makes WSGI great.

> It's just as easy to write a Deferred-using 
> asynchronous application as a blocking one.
> 
> The real issue is that a "proper" WSGI app gets informed of it's 
> environment by the wsgi.multithreaded and wsgi.multiprocess environ 
> variables, so if you really wanted a write-once-run-anywhere, you'd need 
> to be able to handle both scenarios.
> 

By the way, some time ago I proposed a wsgi.asynchronous enviroment 
variable.

> As far as Twisted's WSGI implementation, it should probably support both 
> approaches, maybe where some kind of argument to the WSGIResource class 
> constructor determines what it specifies in the environ dictionary. It 
> should be the responsibility of the WSGI application itself to do the 
> right thing depending on what's inside the environ dict.
> 

I'm not sure that this is possible.
An application is asynchronous or synchronous.

The problem arises when one have to implement a reusable middleware.

> Also, as an aside, I have recently ported web2's WSGI support back to 
> web1, and am using it on a production site with much success. I'd like 
> to contribute it, but I have little to no time to participate in the 
> Twisted review process. Anyone who would like a copy is welcome to it, 
> however...
> 

I'm interested in code that can help me to write a WSGI implementation 
for web1, thanks!

> -phil
> 


Manlio Perillo



More information about the Twisted-web mailing list