[Seaside] Seaside vs Streaming

[Martin Kobetic]

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 ]


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

Cheers,

Martin