[Seaside] Seaside vs Streaming

[Colin Putney]

On Aug 19, 2007, at 3:27 PM, Philippe Marschall wrote:

> 2007/8/19, Colin Putney <cputney at wiresong.ca>:
>>
>> On Aug 19, 2007, at 2:07 AM, Philippe Marschall wrote:
>>
>>> 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
>>> IMHO.
>>
>> Well, if streaming introduces breakage, we needn't do it at all. I'm
>> assuming that this stuff can be made to work with streaming
>> responses. Is there some reason they can't?
>
> Error handling can never work because you already rendered stuff that
> might already be sent.

True, but that doesn't mean errors can't be handled. The default  
error handler might render a walkback half-way down a page that has  
other stuff already rendered. That's not the end of the world for  
development. For deployment, where you might want a custom error  
handler that displayed an error reporter or something, yeah you'd  
have to decide on a tradeoff between streaming and the error reporter.

> WATask can not work with the current implementation (redirect in
> #renderContentOn:).
> WABasicAuthentication would need a completely different implementation
> (no longer a global decoration).

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.

Colin