[Web-SIG] ngx.poll extension (was Re: Are you going to convert Pylons code into Python 3000?)
Manlio Perillo
manlio_perillo at libero.it
Thu Mar 6 12:44:30 CET 2008
Lawrence Oluyede ha scritto:
>> No, you are wrong.
>> WSGI *allows* an implementation to develope extensions.
>>
>> I'm complaining that WSGI 2.0 will break support for truly-async web apps.
>
> Correct me if I'm wrong. WSGI is great on paper and almost great in
> daily use. One of this peculiarities in the "middleware extension
> pattern", which has to foster reuse and spread of middleware doing (I
> hope) one thing and doing right. AFAIK most of the middleware out
> there are not written thinking about async at all. I don't see Twisted
> developers crying out loud begging people to write async middlewares
> and never block.
>
> Don't take it the wrong way but what's the point in fighting so hard
> for WSGI when there's plenty of ways to just ignore it?
>
Because I don't care if people implements WSGI in the wrong way :).
If there is a good middleware, but it is not async friendly, I simply
will not use it and I will try to rewrite it, if it is feasible.
I'm fighting so hard because I think that it is wrong to try to simplify
the WSGI spec so much to make it not usable for writing pute async
applications.
> I know that my statement will upset someone but I think the idea of
> two separate web standard is great. It's too late to force in async in
> the WSGI world and you, with your twisted expertise, should now that
> writing async is hard and asking everyone to not block is even harder
> (that's why even Twisted Matrix has callInThread and something like
> that).
>
I'm not asking everyone to not block! This is not pratical.
And yes, a sync application is very different from a async application.
As an example of HTTP client:
def application(environ, start_response):
c = Connection(...)
r = c.request(...)
for block in r:
yield block
data = r.get_response()
VS
def application(environ, start_response):
c = Connection(...)
r = c.request(...)
data = r.get_response()
I'm not sure that having two standards is the best solution, since it
will complicate the implementation of a WSGI middleware.
Right now, the WSGI module for Nginx can serve both sync and async
applications without problems.
Manlio Perillo
More information about the Web-SIG
mailing list