[Seaside] Seaside vs Streaming

[Martin Kobetic]

Colin Putney wrote:

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

Sounds good. I've started poking around in 2.8, I'll try to direct my attention that way

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

Yup.

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

Actually, maybe one more step before that, finding the session for a given incoming request. There might be some setup that the HTTP server may want to do before starting request execution, and a lot of the setup information is best associated with the session, e.g. session locale. If that's bundled together with the step of getting the headers, then it may be too late to configure for the header computation.

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

Sounds good to me. I don't really care which way the default is set, it's just a default.

> 2) Is there a fundamental reason for this, or is it just a quirk of the 
> way Opentalk HTTP is implemented?

Well, we have a working version of streaming with Opentalk and Seaside 2.7. WAStreamResponse>>stream was the one place that we simply had to patch up, if we wanted to retain any control over the outgoing response. You can't write any additional header before, because Seaside is going to write the status line, and you can't add any headers after, because it will write the body in one swoop as well. Anyway, my point is it's not that we can't make it work, we could even avoid the override if we give up the response completely, but that would be just too much for me :-). There's a state machine behind every protocol somewhere, how are you supposed to update your state if you don't even know what response went out? Seaside needs to decide if it wants to be an HTTP server or not. This "i'll do a bit of HTTP here and there and you do the rest" just doesn't feel right.

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

I was thinking to just stick with Seaside's usual theme, a dictionary of header entries. But again, whatever keeps the folks happy as long as we can decipher it somehow.

I should mention that with the current scheme where the field values are strings we actually have to reparse the values to build our HttpResponse properly, so I would prefer something a bit more structured, but we can do without that.

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

That's why I suggested to keep the current style for the non-streaming case. The response has the content stream and the headers, cookies, etc. The streaming case could use the same form, except for the content you'll get a block to invoke later. I'm hoping that would minimize the amount of changes and seems reasonably simple and consistent interface to me.

Martin