[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