[Web-SIG] ngx.poll extension (was Re: Are you going to convert Pylons code into Python 3000?)

[Manlio Perillo]

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 
> available.  

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.
> 

Ok.
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 
specifications?


> 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.

> The 
> 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.



Manlio Perillo