[Web-SIG] WSGI 2.0

[Manlio Perillo]

Phillip J. Eby ha scritto:
> At 10:13 PM 10/5/2007 +0100, Robin Bryce wrote:
>> That's to much chicken/egg for my tastes. All you are really saying is
>> that the CGI model covers the majority of 'common' use cases. I don't
>> know of anyone who would disagree with this. But as things stand all
>> wsgi-ish implementations which aim to support async/sync are consigned
>> to the dust bin of 'non conformant'. This acts as a strong
>> disincentive to experiment and innovate.
>>
>> If, for clear technical reasons, nothing can be done so support mixing
>> async aware and synchronous applications in WSGI 2.0, then so it goes.
>>

I don't see the reason to mix async and sync applications, in the same 
way that it is not possible to mix a thread unsafe application with a 
threaded server.

WSGI should just *allow* asynchronous applications and middlewares to to 
their job.

As an example, the WSGI write callable cannot be implemented in a 
conforming way in Nginx.

However, if we can allow the write callable to raise an EAGAIN exception 
when the buffer cannot be written to the socket, with the requirement 
that the WSGI application, in this case, MUST return control to the 
server (yielding an empty string as an example), then the write callable 
can be implemented.

 > [...]
> 
> If we were going to try to implement an asynchronous WSGI, what we would 
> *really* need to do is discard the app_iter and make write() the 
> standard way of sending the body.  This would let us implement a CPS 
> (continuation-passing style) API.  

But isn't this possible just using a generator?


> We would also have to change the 
> input stream so that instead of reading from it, we instead passed it 
> functions to be called when input was available, 

Another possible solution is that reading from input is allowed to raise 
an EAGAIN exception, like in the previous example.

 > [...]



Regards  Manlio Perilo