[Seaside] Seaside vs Streaming
cputney at wiresong.ca
Sun Aug 19 03:40:24 UTC 2007
On Aug 16, 2007, at 11:36 AM, Martin Kobetic wrote:
> 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,
> 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.
I suspect that the decision to stream or not to stream should be made
by the session. It's the part of Seaside that coordinates the request/
response cycle, and it's easily accessible for customization by
It seems to me that building a response goes in three phases -
headers, head tag, and body tag. Components might want to influence
the response at each phase, but in order for a response to be
streamed, the phases must be completed in order, and once a phase is
complete, it can't be modified.
So, the communication between the HTTP server and Seaside should have
two parts. First, the session gets to specify any headers it wants
set, including the status line. Then, if appropriate, the session
writes the content to a stream. In the case of html content, the
session will walk the component tree to write the head tag, then
again to write the body.
To address your requirements:
1) The decision to stream or not belongs to the session. I think the
default should be to stream, with non-streamed responses reserved for
weird special cases.
2) Is there a fundamental reason for this, or is it just a quirk of
the way Opentalk HTTP is implemented? Either way, I don't think it's
a problem. Should there perhaps be a ResponseHeaders object that gets
passed around to specify what gets sent back?
3) Yup. The headers phase has to be complete before the next phase
can begin. I suppose for the non-streaming case, we need to be able
to interrupt the sending of the content to change the headers -
otherwise why wouldn't we stream?
More information about the seaside