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
_______________________________________________
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
