Graham Dumpleton wrote: > On 05/10/2007, Phillip J. Eby <[EMAIL PROTECTED]> 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-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
