[Seaside] Seaside vs Streaming

[Janko Mivšek]

Hi Martin,

Martin Kobetic wrote:
> Hi Janko,
> 
> Janko Mivšek wrote:
>> Maybe it will help you a read of Swazoo streaming approach 
>> http://www.swazoo.org/streaming.html. It would be just nice if we 
>> harmonize streaming approaches at API level, so that porting efforts 
>> will be easier.
> 
> OK, I see two separate topics here. One, does the Seaside integration 
> proposal fit your API ? I think it does. Based on your description on 
> the page. I'd expect the streaming hookup to look something like
> 
> 
>     waRequest := anHTTPRequest asWARequest.
>     waResponse := (WADispatcher default handlerForRequest: waRequest) 
> handleRequest: waRequest.
>     waResponse isStreaming
>         ifTrue: [ response := anHTTPRequest streamedResponse.
>             self addHeadersFrom: waResponse to: response.
>             waResponse bodyBlock value: response.
>             response close ]
>         ifFalse: [ "the non-streaming" case ]

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


> As far as harmonizing our streaming APIs, I'm not sure how far we can 
> get there, given the differences between Swazoo and Opentalk. But here's 
> where I'd like to go with this on the Opentalk side. It's actually more 
> about our streaming rewrite of the core HTTP framework than with 
> Opentalk itself. The framework now handles all the various encoding 
> aspects and their combinations by stacking different kinds of streams on 
> top of each other. Chunking is just another layer in that stack. So far, 
> when you build an HttpResponse, you can give it contents as Strings or 
> ByteArrays or as Streams. So typically you'd do something like this 
> given a content stream.
> 
>     response := HttpResponse status: '200'.
>     ... set headers ...
>     response body source: stream
> 
> When you go to write the response on a stream (typically a socket 
> stream) the right stack of streams is built on top of the target stream 
> as different parts of the message are being written.
> 
> What I'd like to add is allowing body content to be provided as a block 
> taking a stream as an argument. The block will be invoked at the right
> time with the stream stack as the argument. 

Here Swazoo is a bit different. On output streaming you get a prepared 
response for streaming and then you stream directly to that response. 
This can be done of course from the block and here we are together again.

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.


> This probably isn't that 
> exciting in the context of a web server where most responses are simple, 
> but it opens up a possibility to build arbitrarily complex multi-part 
> messages, where some parts can be set up as static Strings, some hooked 
> up to external file streams, some as blocks to be executed and the whole 
> thing will just stream straight into the target stream when the message 
> is finally written. At the same time the writer can choose to apply any 
> combination of transfer-encodings (gzip, chunked, etc) without any 
> impact on the message building code. 

This is interesting and I also thought about to go so wide with 
functionality, but then I decided that simplicity is Swazoo's first goal 
and that a response will stay with only one part. But combinations of 
transfer encodings are definitively waiting to be extended at least to 
gzip in Swazoo too.

> As for the Opentalk part, it just 
> needs to build the response object appropriately and hand it a socket 
> stream for writing at the right time. So there isn't really much of an 
> API to speak of. You always just build the response object and writ
> e it on a stream. The management of the connection is completely outside 
> of that scope. Opentalk manages connections (implements cuncurrency 
> limits,etc), manages request execution (forking worker processes), 
> controls the request pipeline for each connection (making sure responses 
> go out in the same order as requests came in regardless of which 
> finishes executing first, as per the HTTP spec), etc. Anyway, I'm not 
> sure if there are any aspects that we could cooperate on (other than 
> comparing notes, which I certainly don't mind). Do you see anything 
> specific ?

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.

Best regards
Janko



-- 
Janko Mivšek
AIDA/Web
Smalltalk Web Application Server
http://www.aidaweb.si