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. I
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,
``read(size)``, that behaves like the ``recv`` method of
``
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,
``read
At 08:25 PM 5/11/2008 -0400, Christopher Stawarz wrote:
Given that the semantics of wsgi.input are, in general, incompatible
with non-blocking execution, I'm inclined to think that such
middleware would either need to be rewritten to use x-
wsgiorg.async.input, or just couldn't be used with asyn
> My thinking is that the server *creates* the environ dictionary, so it can
> just keep a reference to it and update it as needed. Is middleware allowed
> to replace environ with another dict instance before passing it to the
> application? I wasn't aware that this was allowed, but if it is, the
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 don't, then this will bypass middleware that
> > replaces
