[Zope] ZServer streaming output

[Amos Latteier]

At 03:42 PM 7/13/99, Toby Dickenson wrote:
>I've been comparing the streaming output of ZServer and ZopeHTTPServer
>, and come across two disadvantages related to the way ZServer buffers
>writes in memory. Firstly if the output is created faster than the
>client can consume it then the Zope process grows to accomodate the
>buffer. If the streamed output is large then this may not be
>appropriate. 

Hmm. This is a problem with all ZServer responses, not just streaming ones.
Medusa buffers output while switching between connections. You can't send
data to medusa and expect it to block ;-) The most obvious answer to this
is to somehow identify which output buffers are likely to be large and
buffer them in temp files, not in memory.

Jim Fulton and I have talked about adding the RESPONSE interface to allow
you to return a fileobject rather then just a string. Then it would be up
to the published object to know when it was returning a large response and
to use a fileobject instead of a string (or write). Note, you could still
stream using a fileobject by keeping it open and continuing to write to it
after you had returned it to the RESPONSE. Note: This isn't all worked out
yet. And we're open to suggestions.

>Secondly, there seems to be no convenient way to abort
>the method if the client disconnects part way through receiving the
>streamed output. With ZopeHTTPServer in this situation, RESPONSE.write
>would raise an exception.

The interface between ZServer and Zope is pretty restricted, which in
general is a good thing. However it makes it difficult to do things like
communicate network problems back to published objects. ZServer should do
the right thing WRT to disconnected connections, but Zope won't know about it.

Are you finding that ZServer does something wrong (besides not raising an
exception in Zope) when a connection is disconnected? If so, please submit
a bug report to the collector.

Thanks.

-Amos