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

David Reid dreid at dreid.org
Thu Mar 6 18:17:59 EST 2008


On Mar 6, 2008, at 11:06 AM, Manlio Perillo wrote:

> 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.

Read: "So the thing I like about WSGI is that it's actually poorly  
specified"

Why is attempting to adapt a currently synchronous API (the WSGI  
application API is synchronous) It's supposed to allow you to write  
web applications that may be able to run singlethreaded, multithreaded  
or in a multiprocess environment, it doesn't specify an asynchronous  
API.   If it did applications would still need to be written in an  
asynchronous manner.

Threads are the only way to make blocking code appear to be non- 
blocking.
Processes are the only way to make blocking code actually not block.

>> It's just as easy to write a Deferred-using asynchronous  
>> application as a blocking one.

It would be, except it's not at all specified that that is a thing you  
can do.  PEP 333 sure has no mention of Deferreds.

>> 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.

I don't get it.  I don't see the point at all.  I can't make blocking  
code magically not-block.  I could use a middlewear that translated  
from wsgi.asynchronous to a wsgi.multithreaded or wsgi.multiprocess  
implementation for running my synchronous code, but I don't think  
there are any benefits to a wsgi.asynchronous API at all.

I can reasonably write an application that honestly doesn't care if  
it's being serialized, run in threads, or run in seperate processes.   
As soon as you throw wsgi.asynchronous into the mix I lose that ability.

>
>> 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.

Exactly so why should we try to make the same API do both?
>

All that being said I'm perfectly happy to accept patches that enhance  
twisted's wsgi support, but I feel no inclination to support anything  
out of spec.

-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









More information about the Twisted-web mailing list