[Web-SIG] [extension] x-wsgiorg.flush

[Phillip J. Eby]

At 12:36 PM 10/5/2007 +0200, Manlio Perillo wrote:
>Phillip J. Eby ha scritto:
> > [...]
> > Yep, but another argument in favor of getting rid of as much
> > statefulness from the protocol as we can.  Making the status and headers
> > part of the return value entirely eliminates the question of when
> > they're going to get written, and whether they can be changed.
> >
> > (As a side benefit, making the return a 3-tuple makes it impossible to
> > write a WSGI app using a single generator -- thereby discouraging people
> > from using 'yield' like it was a CGI "print".)
> >
>
>
>Wait, what do you mean by """As a side benefit, making the return a
>3-tuple makes it impossible to write a WSGI app using a single generator"""?

I mean that you can't write a WSGI 2.0 application using a single 
generator function, because it has to return a tuple, not an 
iterator.  This will discourage people from thinking "yield" is a 
good way to build up their output, instead of using a StringIO or 
''.join() on a list of strings.


>And what do you mean by """getting rid of as much
>statefulness from the protocol as we can"""?

Most of WSGI 1.0's complexity comes from the sequence of operations - 
when you call start_response(), whether you can call it again, 
whether iteration is in progress, etc.  WSGI 2.0 gives all the 
sequence control to the caller, so that there is no delicate dance of 
calls back and forth.  This especially simplifies middleware that 
manipulates the output stream, because it doesn't need to wrap 
start_response() and write().