[Web-SIG] Proposed WSGI extensions for asynchronous servers

[Phillip J. Eby]

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
>``socket.socket``.  This means that a call to ``read`` will invoke the
>underlying socket ``recv`` **no more than once** and return **at
>most** ``size`` bytes of data (possibly less).  In addition, ``read``
>may return an empty string (zero bytes) **only** if the client closes
>the connection or the application attempts to read more data than is
>specified by the ``CONTENT_LENGTH`` variable.
>
>Before each call to ``read``, the application **must** test the input
>stream for readiness with ``x-wsgiorg.async.readable`` (see below).
>The result of calling ``read`` on a non-ready input stream is
>undefined.

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 wsgi.input.

That is, you will need a way for this spec to support middleware 
that's replacing wsgi.input, without the middleware knowing that this 
specification exists.  In the worst case, it should detect the 
replaced input and give an error or some response that lets the 
application know it won't really be able to use the async feature.



>If ``timeout`` seconds elapse without the file descriptor becoming
>ready for I/O, the variable ``x-wsgiorg.async.timeout`` will be true
>when the application resumes.  Otherwise, it will be false.  The value
>of ``x-wsgiorg.async.timeout`` when the application is first started
>or after it yields each response-body string is undefined.

Er, I think you are confused here.  There is no way for the server to 
know what environ dictionary the application is using, unless you 
explicitly pass it into your extension API.