[Seaside] Seaside vs Streaming

[Colin Putney]

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.

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?

Colin