[Web-SIG] ngx.poll extension (was Re: Are you going to convert Pylons code into Python 3000?)
manlio_perillo at libero.it
Thu Mar 6 20:20:19 CET 2008
Phillip J. Eby ha scritto:
> At 01:11 PM 3/6/2008 +0100, Manlio Perillo wrote:
>> Manlio Perillo ha scritto:
>> > [...]
>> > I'm not sure that having two standards is the best solution, since it
>> > will complicate the implementation of a WSGI middleware.
>> A correction: it should be WSGI gateway and not WSGI middleware.
> On the contrary, it will simplify gateway implementation, if bridges are
I can confirm that implementing WSGI 2.0 is far more simple, however:
1) This is not an issue, since we already have many implementations
of WSGI 1.0: wsgiref, Twisted, Apache, Nginx, flup, ...
2) If you need to implement some extensions (like file_wrapper), then
the implementation is going to become more complex anyway.
> Async gateways would implement WSAI, synchronous gateways
> would implement WSGI.
But I see no need to "invent" a new term (WSAI): the current
specification of WSGI is already good for async gateways/applications.
Is it really the best solution to split WSGI 1.0 into two separate
> The wsgiref library could include a standard bridge or two to go in each
> direction (WSGI->WSAI and WSAI->WSGI), and the gateway would provide
> some support for spawning, pooling, or queueing of threads, where
> threads are needed to make the conversion from WSAI to WSGI (since in
> the other direction, you can simply block waiting for a callback).
If a specification explicitly requires the use of threads, then there is
something bad in it :).
Simply speaking: I want to avoid to use threads in Nginx.
They are not supported by the server.
> APIs could be provided through some standardized environ keys defined in
> the WSAI spec.
Can you make an example? Thanks.
I'm not sure to understand you architecture.
More information about the Web-SIG