Re: WSGI 2.0

Graham Dumpleton wrote:
> On 05/10/2007, Phillip J. Eby <pjetelecommunity.com> wrote:
>> At 07:53 PM 10/4/2007 +0200, Manlio Perillo wrote:
>>> Phillip J. Eby ha scritto:
>>>> At 06:58 PM 10/4/2007 +0200, Manlio Perillo
wrote:
>>>>> But why you are against adding a new
environ value (not necessary named
>>>>> wsgi.asynchronous), that will
explicitly state if the WSGI server will
>>>>> interleave the WSGI application?
>>>> Why do you think it's useful?
>>> For the same reason you think wsgi.multiprocess
is useful.
>> Actually, I don't think it's all that useful; IIRC,
it was added as a
>> compromise to the spec, to fend off a proposal for
a more complex
>> server-capabilities API.  
>>
>> Also, there's an important difference between your
proposed addition
>> and the multiprocess/multithread flags, which is
that there existed
>> frameworks that could be ported to WSGI that only
supported one model
>> or the other.  I.e., frameworks that could only run
multi-threaded,
>> or only multi-process.
> 
> FWIW, one example where the flags are useful is in WSGI
components
> such as browser based debuggers such as EvalException
as they could
> disable themselves or flag an error when used in a
multiprocess web
> server where there would be no guarantee that a
subsequent request
> would end up back at the same process.

Yeah, there's several things I pushed for in WSGI that I
didn't really 
end up needing or wanting later.  But wsgi.multiprocess and

wsgi.multithread have been useful; certainly enough to
warrant their 
simplicity.

   Ian

_______________________________________________
Web-SIG mailing list
Web-SIGpython.org
Web SIG: http://www.python.
org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/bo
nd%40yahoo.com