[Web-SIG] Write buffering (was Re: WSGI uses)

[Phillip J. Eby]

At 04:35 PM 8/19/04 -0700, tony at lownds.com wrote:
> >> If it's a second class citizen to the
> >>iterator why not force all applications to provide their own buffering?
> >
> > I don't see what you mean about buffering.
>
>s/buffering/write()/
>
>An application framework can provide its own write() very easily
>
>def app_framework(env, start_response):
>   start_response(...)
>   buffer = []
>   write = buffer.append
>   ...
>   return buffer

Ah.  But that doesn't allow *streaming* writes.  The specific use case I 
had in mind for using your write() idea was to allow frameworks that 
currently allow streaming writes as a function/method invocation during the 
request execution, to still work under WSGI.

In effect, 'write()' is a backward compatibility mechanism for existing 
code that expects to be able to stream data to the client during request 
execution, and is not currently written in the form of an 
iterator/producer.  (It's also an acceptable mechanism for small/fast 
requests, and frameworks that normally buffer their I/O and would only call 
'write()' once anyway.)

Still, your comments have illustrated to me that there does need to be 
better definition of how flushing is expected to occur, although there is 
only one use case I can think of for it.  Specifically, the only time an 
application needs to ensure that all its pending output has been sent to 
the client, is when it is about to perform some lengthy calculation and is 
using "server push" to display a "please wait" screen before returning the 
real result.  In this case, if I/O is single-threaded (i.e. only happens 
when write() calls are made), and write() isn't guaranteed to be flushed 
(e.g. it's buffered and sent in blocks), then the application would need to 
have a way to say, "no, really, please send it *now*."

On the other hand, if I/O is single-threaded in that fashion, then the 
server should be required to finish every write() before the write() call 
returns.  The write() function should only be allowed to buffer the data if 
another thread is emptying the buffer continuously.

I'll add this to the spec, unless anybody knows of any other use cases for 
either buffering or not buffering writes.