[Web-SIG] WSGI 2.0
ianb at colorstudy.com
Fri Oct 5 17:16:10 CEST 2007
Manlio Perillo wrote:
> Phillip J. Eby ha scritto:
>> At 12:41 PM 10/5/2007 +0200, Manlio Perillo wrote:
>>> Phillip J. Eby ha scritto:
>>>> In other words, those flags were to support legacy frameworks detecting
>>>> that they were in an incompatible hosting environment. However, IIUC,
>>>> there is no such existing framework that could meaningfully use the
>>>> you're proposing, that has any real chance of being portable to
>>>> different WSGI environments.
>>> This is true, but I continue to think that it is worth adding that flag.
>>> Asynchronous support is available in Nginx mod_wsgi, and in the future
>>> someone can implement a WSGI gateway for lighttpd.
>> Right now, the definition of the flag is not sufficiently defined for my
>> taste. You have only proposed that it be set to indicate that
>> interleaved execution is possible -- but it is *always* possible to have
>> interleaved execution in WSGI 1.0, so the only reason to add the flag to
>> WSGI 2.0 would be so a server could promise NOT to interleave
>> execution. And what good is that?
> Ok, here is more useful definition.
> If wsgi.asynchronous evaluates to true, then the WSGI application *will*
> be executed into the server main process cycle and thus the application
> execution *will* be interleaved (since this is the only way to support
> multiple concurrent requests).
Isn't the more important distinction that the application must not
block? Kind of like wsgi.multithread means the application must be
More information about the Web-SIG