On Mar 6, 2008, at 11:06 AM, Manlio Perillo wrote:
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.
Read: "So the thing I like about WSGI is that it's actually poorly
specified"
Why is attempting to adapt a currently synchronous API (the WSGI
application API is synchronous) It's supposed to allow you to write
web applications that may be able to run singlethreaded, multithreaded
or in a multiprocess environment, it doesn't specify an asynchronous
API. If it did applications would still need to be written in an
asynchronous manner.
Threads are the only way to make blocking code appear to be non-
blocking.
Processes are the only way to make blocking code actually not block.
It's just as easy to write a Deferred-using asynchronous
application as a blocking one.
It would be, except it's not at all specified that that is a thing you
can do. PEP 333 sure has no mention of Deferreds.
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.
I don't get it. I don't see the point at all. I can't make blocking
code magically not-block. I could use a middlewear that translated
from wsgi.asynchronous to a wsgi.multithreaded or wsgi.multiprocess
implementation for running my synchronous code, but I don't think
there are any benefits to a wsgi.asynchronous API at all.
I can reasonably write an application that honestly doesn't care if
it's being serialized, run in threads, or run in seperate processes.
As soon as you throw wsgi.asynchronous into the mix I lose that ability.
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.
Exactly so why should we try to make the same API do both?
All that being said I'm perfectly happy to accept patches that enhance
twisted's wsgi support, but I feel no inclination to support anything
out of spec.
-David
"Usually the protocol is this: I appoint someone for a task,
which they are not qualified to do. Then, they have to fight
a bear if they don't want to do it." -- Glyph Lefkowitz
_______________________________________________
Twisted-web mailing list
[email protected]
http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web
