WSGI support (was [Twisted-web] Re: status of Twisted Web and
Web 2)
Manlio Perillo
manlio_perillo at libero.it
Thu Mar 6 14:06:52 EST 2008
Phil Christensen ha scritto:
> On Mar 6, 2008, at 10:56 AM, David Reid wrote:
>> On Mar 6, 2008, at 2:00 AM, Manlio Perillo wrote:
>>> I think that having a "pure" asynchronous WSGI implementation in
>>> Twisted Web that implements this extension can be a good starting
>>> point for trying to standardize asynchronous web applications.
>>>
>>> P.S.: the wsgi.pause_output extension, proposed some years ago here
>>> by Donovan Preston should be very easy to implement using ngx.poll,
>>> and a pipe.
>>
>> Does anyone support said extension? Does everyone support the same
>> pause_output? Or just functions of the same name?
>>
>> It shouldn't be very hard to add support for it to Twisted.web2's WSGI
>> implementation either, but I don't much see the point if no one else
>> supports it. I'm not convinced that WSGI is at all a useful means of
>> writing asynchronous web applications. I think WSGI's only benefit is
>> that it allows you to almost write your application code once and run
>> it on multiple containers.
>
> I'd have to disagree (slightly). There's nothing about WSGI that makes
> it only applicable to one approach or another (that is, synchronous
> versus asynchronous).
Right.
This is what makes WSGI great.
> It's just as easy to write a Deferred-using
> asynchronous application as a blocking one.
>
> The real issue is that a "proper" WSGI app gets informed of it's
> environment by the wsgi.multithreaded and wsgi.multiprocess environ
> variables, so if you really wanted a write-once-run-anywhere, you'd need
> to be able to handle both scenarios.
>
By the way, some time ago I proposed a wsgi.asynchronous enviroment
variable.
> As far as Twisted's WSGI implementation, it should probably support both
> approaches, maybe where some kind of argument to the WSGIResource class
> constructor determines what it specifies in the environ dictionary. It
> should be the responsibility of the WSGI application itself to do the
> right thing depending on what's inside the environ dict.
>
I'm not sure that this is possible.
An application is asynchronous or synchronous.
The problem arises when one have to implement a reusable middleware.
> Also, as an aside, I have recently ported web2's WSGI support back to
> web1, and am using it on a production site with much success. I'd like
> to contribute it, but I have little to no time to participate in the
> Twisted review process. Anyone who would like a copy is welcome to it,
> however...
>
I'm interested in code that can help me to write a WSGI implementation
for web1, thanks!
> -phil
>
Manlio Perillo
More information about the Twisted-web
mailing list