[Seaside] Seaside vs Streaming
janko.mivsek at eranova.si
Thu Aug 16 15:51:13 UTC 2007
Maybe it will help you a read of Swazoo streaming approach
http://www.swazoo.org/streaming.html. It would be just nice if we
harmonize streaming approaches at API level, so that porting efforts
will be easier.
Martin Kobetic wrote:
> Here's how I understand current streaming integration in Seaside. If you
> want the response to "stream" back to the client, the HTTP server has to
> set the responseStream: on the WARequest object it builds before handing
> it off to Seaside with the handleRequest: call. If the responseStream is
> set Seaside will create WAStreamingResponse (instead of WAResponse),
> which instead of creating an internal stream for the response contents
> will use the provided one. However since this is expected to be the real
> socket stream, it will first write complete HTTP header into it on the
> first access of the #stream. By the time the HTTP server gets control
> back from #handleRequest: the entire response has already been written
> into the socket.
> Here's what I see as problematic with the above solution:
> 1) I think the decision to stream or not doesn't belong to the HTTP
> server. As was previously pointed out, some components must stream, some
> can work either way and some must not stream. It's the components that
> know enough to make that decision, not the server. With the current
> setup, the best you can get is a global flag for streaming on the server
> which will either force all components to stream or all components to
> not stream.
> 2) IMO having the WAStreamingResponse write the header breaks the
> separation of concerns between the HTTP server and Seaside. The HTTP
> server may want to add fields, filter others, what not. Moreover the
> server may want to package the response differently, multipart message
> rather than a simple body, etc. Nothing like that is possible with the
> current setup.
> Here's what I'd like to have as the integration hooks in Seaside. Leave
> the decision about streaming to the component. If the component doesn't
> want to stream it can return WAResponse with the header dictionary and a
> body stream as before. If the component does want to stream it will
> return a WAStreamingResponse with header dictionary and a block. The
> block will take a stream to write the body into as an argument and will
> be invoked some time later when the time to write the body into the
> socket comes. If a server cannot stream it can simply invoke the block
> with an internal stream and then proceed as with regular WAResponse.
> For backward compatibility we could still support the responseStream:
> mechanism. If the responseStream is set, Seaside can just write the
> headers into it as before and then invoke the body block with the
> Stream. If the response is non-streaming, we can still just make it
> write into the provided stream.
> That's it.
> Now my proposal clearly goes beyond just addressing the two issues
> mentioned above. It's what I think I'd like to have. However here are
> some key points that I think are necessary.
> 1) Components decide about streaming, not the server. Implementing this
> should be pretty easy, have separate hierarchies for streaming and
> non-streaming components, or have a flag somewhere, etc. A component
> could even decide dynamically and stream in some cases and not stream in
> 2) Header fields are *always* provided separately and not written by
> 3) The streaming action writes just the body of the response
> Does any of this sound reasonable ?
Smalltalk Web Application Server
More information about the seaside