[Seaside] Seaside vs Streaming

[Martin Kobetic]

Avi Bryant wrote:
> 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.

Most likely my Seaside terminology is off. I don't really know that much about Seaside internals, I'm just looking at it from point of view of the external HTTP server integrating with it. When I said "component returns response", I really meant the #handleRequest: call (or an equivalent) returns a response. But what I see crucial is that the decision to stream or not for that particular response should be made by specific "pieces" (to avoid any Seaside specific terminology here) implemented or used by the web application code. E.g. the author of the Commet support should be able to just set a flag somewhere or subclass the right class or whatever would be most suitable way to express the notion that these "pieces" need to stream the response. How exactly is the decision expressed at that end isn't really my concern as long as the decision is somehow conveyed to the layers building the WAResponses and executed there by giving it a stream or a block. The "block" part of course
 assuming we agree with my proposal. There are other ways to handle the streaming type than using a block, but I wanted to suggest my preference.

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

I'm not sure I get this part. I'm just suggesting changes to the way response streaming is currently hooked up to Seaside. I don't view streaming to be "exceptional" and non-streaming to be "normal". Just two functionally different ways to push a response back, each suitable for different purposes. I'm probably oversimplifying the situation somewhat, e.g. it's up for discussion how to handle the cases where some parts of the page require streaming and some not. But hopefully there is a reasonable set of rules that can be set up for these issues. Presumably, in the current situation it will just fail in some (possibly non-obvious) way. Maybe simply returning an error explaining the nature of the problem is actually better than getting a somewhat broken page back. To boil down my set of basic requirements some more, avoiding talk about parts I'm not that familiar with:

1) The decision to stream or not doesn't belong to the HTTP server
2) Seaside shouldn't write HTTP headers directly into the socket, ever.
3) In the streaming case the HTTP server should be able to obtain the response headers from Seaside before handing the socket over to Seaside for the body to be written.

Whatever solution we can come up with that satisfies the 3 points above, works for me.

Does that make it clearer ?

Martin