[Web-SIG] [RFC] x-wsgiorg.suspend extension

[Graham Dumpleton]

On 13 April 2010 00:39, Manlio Perillo <manlio_perillo at libero.it> wrote:
> P.J. Eby ha scritto:
>> At 01:25 PM 4/12/2010 +0200, Manlio Perillo wrote:
>>> The purpose of the extension if to just have a standard interface that
>>> WSGI applications can use to take advantage of the possibility, offered
>>> by asynchronous server, to suspend execution and resume it later.
>>
>> WSGI has this ability now - it's yielding an empty string.  Yielding an
>> empty string is a hint to the server that the application is not ready
>> to send any output, and the server is free to schedule other
>> applications next.  And WSGI does not require the application to be
>> rescheduled any time soon.
>>
>> In other words, if saying "don't call me for a while" is the purpose of
>> the extension, it is not needed.  As Graham says, the thing that would
>> actually be needed is a way to tell the server when to poll the app again.
>>
>
> Just yielding an empty string does not give the server some important
> informations.
>
> As an example, with x-wsgi.suspend application can specify a timeout,
> that tells the server that the application must be resumed before
> timeout milliseconds have elapsed.
>
> And x-wsgi.suspend returns a callable that, when called, tell the server
> to poll the app again.

There are other ways of doing that, the callable doesn't need to be in
the WSGI environment. This is because since it is single threaded, the
WSGI server need only record in a global variable for that WSGI
application some state about the current request. The separate
function to note the suspension can then lookup that and does what it
needs to. In other words, you don't need the WSGI environment to
maintain  that relationship.

Having the timeout as argument is also questionable anyway. All you
really need to do is to tell the WSGI server that I don't want to be
called until I tell it otherwise. The WSGI application could itself
handle the timeout in other ways.

Overall one could do all of this without having to do anything in the
WSGI environment. As PJE points out, it can be done by relying only on
the ability to yield an empty string. Everything else can be in the
application realm with the application normally being bound to a
specific WSGI server/event loop implementation, thus no portability.

The problem of a middleware not passing through an empty string
doesn't even need to be an issue in as much as the application could
track when it requested to be suspended and if called into again
before the required criteria had been met, it could detect a
middleware that wasn't playing by the rules and at least raise an
error rather than potentially go into blocking state and tight loop.

One could theoretically abstract out an interface for a generic event
system, but what you don't want is a general purpose one. You want one
which is specifically associated with the concept of a WSGI server.
That way the API for it can expose methods which specifically relate
to stuff like suspension of calling into the WSGI application for data
until specific events occur. That abstract interface could then be
implemented as concrete implementations for specific event based WSGI
servers. Because a handle to that instance would be needed by the
application, including outside context of a request, then a
requirement of the interface may be that this handle to the WSGI
server event interface be passed as argument to the WSGI application
when it is created.

So, you could come up with a standard for asynchronous WSGI, but the
WSGI specification itself doesn't need to change nor additional keys
put in the WSGI environment. Instead, any standardised interfaces
exist outside of that and relates more to the interaction between
application and underlying WSGI server directly, independent of a
specific request in the large part.

Graham