[Seaside] Seaside vs Streaming

[Martin Kobetic]

Janko Mivšek wrote:
> Yes, that's actually almost the same as Swazoo approach.Maybe just a line:
> 
>     waResponse bodyBlock value: response.
> 
> How is that block implemented. Something like:
> 
>     [:streamedResponse |
>        [elements atEnd] whileFalse:
>            [streamedResponse nextPutAll: elements next asHTML] ?
> 

The bodyBlock is something that Seaside would give you to execute with the socket stream as an argument. When the block runs all the Seaside magic happens that eventually produces the characters that should go into the body of the HTTP response. Whatever that is. The block represents the deferred execution of the request by Seaside, to be executed when the socket stream is ready to receive the response body. That's the idea anyway. In the Swazoo case the "socket stream" is represented by your streaming response object. In our case it will be the stream stack we prepare for the body.

> But on input streaming (file uploads) you actually provide a streaming 
> block to Swazoo, which is then called when post data parsing occurs. And 
> that parsing is deferred (request is not received in full immediately) 
> until you provide that block. So the framework have a time to decide 
> what to do with a request - to prepare a file with a right filename on 
> the right place to stream into, for instance.

That however is processing of the incoming request. That's different "streaming" from what I'm discussing here. You can do input streaming and still not stream the response. In that case you're not really "streaming" in the sense that the web folks care about. AFAIU they really mean the response streaming when they talk about "streaming".

> I think that we don't need to harmonize internals of both servers, 
> because their goals are different. Swazoo goal is portability, 
> simplicity and performance, while one of Opentalk goals seems to be a 
> complete implementation of HTTP protocol.
>
> But on API level we are actually similar enough it seems. And 
> harmonizing don't mean that they need to be equal. And because they are 
> similar enough, this will definitively help both web servers to be 
> connected to the frameworks and interchanged at the will, easily.

Yup, that's why I wanted to discuss this here. I hope that any Kom folks out there will find the time to think about my proposal and chime in too. It seems to me that the current "all or nothing" approach to streaming isn't ideal even from the Seaside point of view, so hopefully there's enough motivation all around to think about ways to improve it.

Cheers,

Martin