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