Phillip J. Eby ha scritto:
> At 09:37 AM 3/6/2008 +1100, Graham Dumpleton wrote:
>> You probably need to explain the second half of that sentence a bit
>> better. From memory the WSGI 1.0 specification says that for an
>> iterable, the headers should be sent upon the generation of the first
>> non empty string being yielded. How does what you are doing relate to
>> that, are you not doing that? Why would WSGI 2.0 necessarily be any
>> different and cause a problem?
>
> Because (in concept anyway) WSGI 2.0 is synchronous with respect to
> headers -- you don't get to yield empty strings and *then* return the
> headers.
>
> Personally, I see truly-async web apps as a niche, because in order to
> write a useful async app, you need *other* async APIs besides your
> incoming HTTP one.
Yes, this is true.
But I have to say that:
1) the asynchronous model is the "right" model to use to develope
robust and scalable applications (expecially in Python).
The fact that it is a niche does not means that it should not be
supported and promoted.
> Which means you're going to have to write to Twisted
> or some other library's API, or else roll your own.
This is true, but there are already some working(?) asynchronous clients:
pycurl and psycopg2.
You don't need to use the web server "private" API.
An HTTP client and an a database client is usually all you need in a web
application (well, you usually need also an SMTP client, but since a
server probably has a local SMTP daemon running, this should not be a
problem)
> At which point,
> connecting your app to a web server is the least of your concerns.
This is not always true.
> (Since it has to be a web server that's compatible with the API you're
> using, which means you might as well use its native API.)
>
No, this is not correct.
The ngx.poll extension should be easy to implement in a "standard"
server (I would like to write a reference implementation for wsgiref).
Moreover it is not impossible to write a pure async WSGI implementation
in Twisted Web, and then having it support the poll extension.
Then, a portable application can just use pycurl or psycopg2 + the poll
extension and should be portable.
Of course many WSGI implementations will not implements an "optimized"
version of the poll extension, but isn't the same true for
wsgi.file_wrapper?
> That having been said, I don't see a problem with having a Web Server
> Asynchronous Interface (WSAI?) for folks who want that sort of thing.
> Ideally, such a thing would be the CPS (continuation-passing style)
> mirror of WSGI 2.0. Where in WSGI 2.0 you return a 3-tuple, in WSAI
> you'd essentially use start_response() and write().
>
Why write?
It's only a problem.
An asynchronous application should just use a generator.
This solves some problems, like the consumer producer problem.
Moreover it is also more convienent to use (IMHO).
> In essence, you might say that WSGI 1.0 is a broken-down version of a
> hideous crossbreeding of pure WSGI and pure WSAI. It would probably be
> better to split them and have bridges. A truly-async system like
> Twisted has to (effectively) do WSAI-WSGI bridging right now, but if we
> had a WSAI standard, then there could perhaps be third-party bridges.
>
> Even so, it's quite a niche: Twisted, nginx, and...? I know there are a
> handful of async frameworks, and how many of those have web servers
> included?
>
Yes, this is a problem
But what makes WSGI 1.0 great, is that it is able to support this niche.
Thanks 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
