[Web-SIG] WSGI 2.0

[Ian Bicking]

Phillip J. Eby wrote:
> I was thinking of something a bit simpler; the environ key would be an 
> object that, when called, tells the server that it's okay to resume 
> iteration attempts on the application.  A sort of "put me back on the 
> queue for iteration" call.  The callback would have to be safe to call 
> from any thread at any time, and must not re-enter anything, just 
> re-enable iteration.

OK, that makes sense.  So there's something like 
environ['wsgi.server_resume'] in the environment, and the app yields 
something that indicates a pause, then calls that value to undo the pause?

>>> Ideally, this should be done in a way that's easy for middleware to 
>>> handle; a flush signal should be handled by the middleware *and* 
>>> passed up the chain, while any other async signals would be passed 
>>> directly up the chain (unless it's something like "pause for input" 
>>> and the middleware controls the input).
>>> If we do this right, it should be easier to write middleware that 
>>> works correctly with respect to buffering, since the issues of 
>>> flushing and pausing now become explicit rather than implicit.  (This 
>>> should make it easier to teach/learn as well.)
>>
>> In terms of buffering, I can't think of many cases where it would 
>> matter.  Either the middleware passes back the response with no 
>> changes, or it needs to consume the entire response body (and probably 
>> headers and maybe status) to do whatever transformation it needs to do.
>>
>> Things like pauses and async signals would ideally be passed upstream, 
>> but flushes and content would all be consumed by the middleware.
> 
> I can't think of any condition where middleware would *not* pass all of 
> these up to its caller.  In the case of a "flush", it needs to first 
> yield any buffered output, but it *must* still yield the flush.

Is there any use to this?  If you are transforming output, the flush is 
unlikely to flush anything; all output will be buffered.

> For example, if you're doing server push, then the app should yield a 
> flush prior to each new content boundary.  If the middleware is doing 
> compression or some such, then it needs to restart encoding after each 
> content boundary, as well as flush the prior encoded output.

I suppose server push is the only place where flush really matters, and 
most output transformations will simply break server push.  As long as 
the async signals are easy to detect (e.g., an integer or tuple) then 
that's fine.

-- 
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org
             | Write code, do good | http://topp.openplans.org/careers