[Seaside] Seaside vs Streaming

[Martin Kobetic]

> 
> But if the session made a pass over the component tree for each phase, 
> these problems could be easily overcome. Redirects or 401 status codes 
> could be set in the headers pass instead of during rendering, and so no 
> big structural changes would be needed.
> 
> I'm assuming here that there is some desire to have Seaside do 
> streaming, or why would we have the discussion? If we don't make the 
> necessary changes for all Seaside features to work with streaming 
> responses, then we may as well not bother trying to support it at all. 
> If it's reserved for a special optimization case, then it will never get 
> used anyway.

My understanding is, that some of the new hip and cool web programming techniques require the streaming hookup. So presumably the decision is: do we want Seaside to support those or not. The HTTP server can handle direct streaming of files (in both directions) without explicit streaming support in Seaside (if we avoid defeating it with things like WAFile>>contents). So it's not about handling large files. It's about being able to do new kinds of web programming. Assuming the decision is yes, we want streaming, then being able to either stream or not for any particular response should yield the best of both, and should suite most purposes. So I'm not sure what exactly is the argument here. Does the streaming hookup proposed here seem too complicated, compared to the benefits?

Martin