[Web-SIG] WSGI 2.0

[Phillip J. Eby]

At 05:14 PM 10/5/2007 +0200, 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
> >> flag
> >> > 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).

I still don't see how this is *useful*.  What will the application 
*do* with this information?