[Seaside] Seaside vs Streaming
philippe.marschall at gmail.com
Sun Aug 19 09:07:44 UTC 2007
2007/8/19, Colin Putney <cputney at wiresong.ca>:
> 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,
> > 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.
> 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
> Seaside applications.
> 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.
Since when are WATask and handling of errors during the rendering
phase or http basic authentication special cases? Given all the
breakage http response streaming introduces it should be default off
> 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?
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
More information about the seaside