[Web-SIG] [extension] x-wsgiorg.flush

[Manlio Perillo]

Phillip J. Eby ha scritto:
> At 10:57 AM 10/4/2007 +0200, Manlio Perillo wrote:
>> Phillip J. Eby ha scritto:
>> > [...]
>> >> There is a problem here: a WSGI gateway is not allowed to send headers
>> >> until the app_iter yields a non empty string or the iterator is 
>> exausted.
>> >
>> > Argh.  You're right.  I forgot about that bit.  It has been a few too
>> > many years since I worked on the spec.  :)
>> >
>>
>> 07-Dec-2003!
>> And yet it seems that WSGI is not pervasively used.
> 
> What do you mean?  Can you name a popular Python web framework or 
> library that doesn't either use or support WSGI?
> 

Django, as an example, uses WSGI "only as a backend".
Django design is not based on WSGI, it is WSGI that is adapted for Django.

An interesting example: to add support for CGI, it seems that the 
preferred method is to add a direct Django adapter for CGI, instead of 
using a WSGI adatper for CGI.


> 
>> > Still, this is yet another example of why WSGI 2.0 is a big improvement
>> > in simplicity.  So I still would rather see more effort put into 
>> getting
>> > WSGI 2.0 written and into widespread use, than creating niche 
>> extensions
>> > to 1.0.
>>
>>
>> My implementation of mod_wsgi for nginx implements WSGI 2.0, and now I'm
>> removing the limitation that the app_iter must yield only one item.
> 
> Eh?  I don't understand what you mean by "app_iter must yield only one 
> item".  


   return '200 OK', [('Content-Type', 'text/plain')], ['a', 'b']

is not allowed.
The response object can be a generic iterator, however.

> In WSGI 2.0 the application return signature is a three-item 
> tuple, the third item of which is a WSGI 1.0 response object.
> 
> 
>> However there is a problem with WSGI 2.0.
>>
>> Suppose that I execute an asynchronous HTTP request to obtain some data
>> from a remote server.
>>
>> I can use the yet to be implemented wsgi.pause_output extension for
>> this, or an extension for interfacing with nginx subrequest API.
> 
> That won't be possible in WSGI 2.0 - it's a purely synchronous API. 

This is the reason why I don't like WSGI 2.0 :).

However I have to admit that developing a full asynchronous application 
is not easy, notably when we have to interact with a database and a 
transaction.

It is really so hard to implement WSGI 1.0 and to write middlewares for it?
Is this really causing problems for WSGI adoption?

I think that WSGI 2.0 should simply correct some problems in WSGI 1.0, 
and clarify some points, since now we have a WSGI implementation for 
Apache and Nginx.


 > You
> can pause body output by yielding empty strings, but you need to have 
> already decided on your headers.
> 

And this will make asynchronous applications not really useful, IMHO...
But here I will say more once I'll implement some asynchronous 
extensions for nginx mod_wsgi.

It's very unfortunate that the WSGI implementation in Twisted just uses 
threads instead of doing some experimentation.

 > [...]


Regards  Manlio Perillo