[Web-SIG] ngx.poll extension (was Re: Are you going to convert Pylons code into Python 3000?)

[Graham Dumpleton]

Let me get this right. You are complaining that the WSGI 2.0 would
break your non standard extension which was never a part of the WSGI
1.0 specification to begin with.

I also find it interesting that in the very early days you were
pushing very very hard for WSGI 2.0 to be specified and you had no
intention of even supporting WSGI 1.0 style interface. Now things seem
to be the complete opposite.

Anyway, your complaint seems to resolve around:

"""An asynchronous application is simply impossible to develope with the
current draft of WSGI 2.0, since I need to send the headers after some
steps in the application iterator."""

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?

Graham

On 06/03/2008, Manlio Perillo <manlio_perillo at libero.it> wrote:
> Brian Smith ha scritto:
>  > Manlio Perillo wrote:
>  >> Fine with me but there is a *big* problem.
>  >>
>  >> WSGI 2.0 "breaks" support for asynchronous applications
>  >> (since you can no more send headers in the app iter).
>  >
>  > WSGI 1.0 doesn't guarentee that all asynchronous applications will work
>  > either, because it allows the WSGI gateway to wait for and buffer all
>  > the input from the client before even calling the application callable.
>  > And, it doesn't provide a way to read an indefinite stream of input from
>  > the client, which is also problematic.
>  >
>  > Anyway, please post a small example of a program that fails to work
>  > because of these proposed changes for WSGI 2.0.
>  >
>  > Thanks,
>  > Brian
>  >
>
>
>  Attached there are two working examples (I have not committed it yet,
>  because I'm still testing - there are some problems that I need to solve).
>
>
>  The `curl_client` module is an high level interface to pycurl.
>
>  The `nginx-poll-proxy.py` script is an asyncronous WSGI application that
>  implements an HTTP proxy.
>
>  The `nginx-poll-sleep.py` script is a simple asynchronous WSGI
>  application that get the content of an HTTP resource using poll just to
>  "sleep" (suspend execution) for a fixed amount of time.
>
>
>  NOTE: I have also added a `ngx.sleep` extension, but I'm going to remove
>  it since the same behaviour can be obtained with ngx.poll.
>
>
>  An explanation of the interfaces
>  --------------------------------
>
>  The ngx.poll extension is based on the Python stdlib select.poll interface.
>
>  There are two constants: `ngx.WSGI_POLLIN` and `ngx.WSGI_POLLOUT`.
>  These are defined in the WSGI environment, but their value is "know"
>  (`0x01` and `0x04`) and can be used for bit masking.
>
>  The `ngx.connection_wrapper(fd)` function takes as input a file
>  descriptor (as integer) and returns a Connection wrapper object, to be
>  used for later operations.
>
>
>  The Connection wrapper object has the following methods:
>  - fileno():
>       return the associated socket descriptor
>  - register(flags):
>       register the connection with the server "reactor";
>       flags is a bit mask of ngx.WSGI_POLLIN and ngx.WSGI_POLLOUT
>  - deregister(flags=None):
>       deregister the connection from the server "reactor"
>  - close:
>       close the connection object, deregisterering it from the server
>       "reactor" if still active.
>       XXX it also can close the socket, but this should be done by the
>           client
>
>  The last function is `ngx.poll(timeout)`.
>  When called, the user *should* yield an empty string (yielding a non
>  empty string will result in an "undefined behaviour").
>
>  The WSGI application iteration will be suspended until a connection is
>  ready for reading or writing, or the timeout expires.
>
>  The `ngx.poll` function returns a callable that, when called, returns a
>  tuple with the connection object "ready" (or None if timedout) and a
>  flag indicating if the connection is ready for reading or writing.
>
>  NOTE: due to the internal architecture of the Nginx event module (it
>         have to support several different event systems), mod_wsgi for
>         Nginx will only return ngx.WSGI_POLLIN or ngx.WSGI_POLLPUT,
>         *never* ngx.WSGI_POLLIN | ngx.WSGI_POLLPUT.
>
>         Also, no error status is reported.
>
>
>
>  That's all.
>
>  An asynchronous application is simply impossible to develope with the
>  current draft of WSGI 2.0, since I need to send the headers after some
>  steps in the application iterator.
>
>
>  So, please, don't "ruin" the WSGI specification just to make it more
>  easy to implement and to use.
>  For me asynchronous support is very important.
>
>
>  P.S: I have chosen to implement this interface, instead of
>        `wsgi.pause_output`, because IMHO it is very easy to implement for
>        "normal" servers.
>
>        Moreover it is also more simple to use, with a very "natural"
>        interface, and it avoids the use of callbacks and a more strict
>        interaction with the server "reactor".
>
>
>  Regards  Manlio Perillo
>
>
> _______________________________________________
>  Web-SIG mailing list
>  Web-SIG at python.org
>  Web SIG: http://www.python.org/sigs/web-sig
>  Unsubscribe: http://mail.python.org/mailman/options/web-sig/graham.dumpleton%40gmail.com
>
>
>