[Web-SIG] WSGI 2.0

[Ian Bicking]

Graham Dumpleton wrote:
> On 05/10/2007, Phillip J. Eby <pje at telecommunity.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