(I'm new to the list, so please forgive me for making my first post a
specification proposal :)
Browsing through the list archives, I see there's been some
inconclusive discussions on adding better support for asynchronous web
servers to the WSGI spec. Since such support would be very useful
On May 5, 2008, at 10:08 PM, Graham Dumpleton wrote:
If write() isn't to be returned by start_response(), then do away with
start_response() if possible as per discussions for WSGI 2.0.
I think start_response() is necessary, because the application may
need to yield for I/O readiness (e.g.
On May 6, 2008, at 6:17 AM, Manlio Perillo wrote:
I'm glad to know that there are some other people interested in
asynchronous application, do you have seen my extensions to WSGI in
my module for Nginx?
Yes, I have, and I had your module in mind as a potential provider of
the AWSGI
On May 6, 2008, at 8:51 PM, Ionel Maries Cristian wrote:
- there is no support for chunked input - that would require having
support for readline in the first place,
Why is readline a requirement for chunked input? Each chunk specifies
its size, and the application receiving a chunk just
On May 7, 2008, at 3:35 PM, Duncan McGreggor wrote:
It's my understanding that greenlets are python, not C. Are you
thinking
of tasklets in stackless?
The version for CPython is a C extension module. Have a look at the
comments in
http://svn.red-bean.com/bob/greenlet/trunk/greenlet.c
On May 7, 2008, at 5:36 PM, Ionel Maries Cristian wrote:
The way I see it asynchronous wsgi is just a matter of deciding how
to handle the input asynchronously - a asynchronous input wsgi
extension specification.
Another crucial element is the ability to perform non-blocking I/O on
other
This is a revised version of my AWSGI proposal from last week. While
many of the details remain the same, the big change is that I'm now
proposing a set of extensions to standard WSGI, rather than a separate
specification for asynchronous servers.
The updated proposal is included below.
On May 11, 2008, at 7:05 PM, Phillip J. Eby wrote:
At 06:15 PM 5/11/2008 -0400, Christopher Stawarz wrote:
Non-blocking Input Stream
~
The ``x-wsgiorg.async.input`` variable provides a non-blocking
replacement for ``wsgi.input``. It is an object with one method
On May 12, 2008, at 12:45 AM, Ionel Maries Cristian wrote:
On Mon, May 12, 2008 at 3:25 AM, Christopher Stawarz [EMAIL PROTECTED]
wrote:
On May 11, 2008, at 7:05 PM, Phillip J. Eby wrote:
For this to work, you're going to need this to take the wsgi.input
object as a parameter. If you
On May 12, 2008, at 12:18 PM, James Y Knight wrote:
There are other issues. How do you do a DNS lookup? How do you get
process completion notification? Heck, how do you run a process?
These are valid questions that I'm not attempting to address with this
proposal. So maybe the title of my
On May 12, 2008, at 5:07 PM, James Y Knight wrote:
Surely you need DNS lookup to make a socket connection? Do you mean
to provide that in an external library via a threadpool?
No, I don't mean to, because I don't care enough to bother. But if
you or someone else did, you'd be free to.
This is the third draft of my proposed extensions for better
supporting WSGI apps on asynchronous servers. The major changes since
the last draft are as follows:
* The title and abstract now accurately reflect the scope of the
proposal.
In addition, the extensions are now in the
On May 21, 2008, at 1:34 PM, Manlio Perillo wrote:
Instead, the spec recommends that async servers pre-read the
request body
before invoking the app (either by default or as a configurable
option).
This is the best solution most of the time (but not for all of the
time), especially if
On May 22, 2008, at 4:51 AM, Manlio Perillo wrote:
I'm reading the PEP 342, and I still think that this will not work
as I want for Nginx (where I have no control over the scheduler).
In fact the PEP 342 says:
However, if it were possible to pass values or exceptions *into* a
generator at
On May 22, 2008, at 6:21 PM, Manlio Perillo wrote:
That way, the server doesn't have to rewrite the request, and the
application doesn't need to know how to interpret the files.*
parameters.
How to interpret the files.* parameters is not really a problem.
It's a problem for a portable
15 matches
Mail list logo
