[Seaside] Seaside vs Streaming

[Avi Bryant]

On 8/16/07, Martin Kobetic <mkobetic at cincom.com> wrote:

> 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.

Just to be clear - it is exceptional for a component to return any
sort of response; normally a component is just expected to render a
small piece of HTML to whatever the current response is (or there
might not be one at all, if we're building up HTML on an internal
stream for some purpose).  Returning a response means that a component
is taking over the page and ignoring anything that might have come
before it in the render tree.  Usually this doesn't happen from
components at all (or from their render phases at least), but instead
from some callback that wants to shortcut the usual cycle.

Is your suggestion that streaming be treated as an exceptional thing
rather than part of the standard rendering of a component - so, as a
slightly awkward big gun to pull out when optimization was crucial or
when you wanted a comet-like push interface, rather than as a
transparent framework-wide optimization?  I think that's probably ok
(given that nobody has achieved the latter goal so far), just want to
make sure.

Avi