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