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

[Manlio Perillo]

David Reid ha scritto:
> [...]
>> Right.
>> This is what makes WSGI great.
> 
> Read: "So the thing I like about WSGI is that it's actually poorly 
> specified"
> 

No, I disagree.

WSGI is able to support asynchronous applications since you can send 
headers in the application iterable, and the application iterable can be 
a generator, so the WSGI gateway can suspend the iteration at any time.

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

Ok, but I'm not speaking about generic code.
I'm speaking about code specifically written for an asynchronous WSGI 
implementation.

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

Right.

There is no need for such variable, the application can just check for 
asynchronous extensions.

However wsgi.asynchronous does make sense if the WSGI gateway implements 
a whole set of asynchronous extensions, like poll or async reading from 
wsgi.input.

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

Not necessary true.
If you look at the simple nginx-poll-sleep example, then it easy to use 
two separate HTTP clients, depending on the presence of ngx.poll extension.

Of course, your application *needs* to return a generator, but this is 
not a problem.

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

The API does not do anything.
It simply should support both models (and this is possible, it is 
*already* possible)




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

Manlio Perillo