[Seaside] [VW][7.6] Streaming?

Martin Kobetic mkobetic at cincom.com
Mon Apr 21 21:18:02 UTC 2008

I have to admit I'm sooo not ready for this discussion, but I guess I better say something.

First, when we were working on streaming integration with Seaside 2.8 back in August last year, Seaside 2.8 was nearing 
its release and it was quite late for any disruptive changes. So we tried to just hack our way through the problem and 
came up with an integration solution that we didn't like but seemed to be working. We were planning to ship 2.8 with our 
hack-ish solution and revisit streaming later at a more opportune time. Of course, as we were nearing our VW7.6 freeze 
dates we found out the hack-ish solution still had some issues, and in the end we decided to disable the streaming 
support altogether for the 7.6 release. Right now we're working to get Velocity 1.0 out and consequently didn't have 
time to look at Seaside 2.9 at all. So I feel completely unprepared to discuss this particular problem.

However to say at least something more specific, IIRC one of the main problems we ran into was that the streaming 
support back in Seaside 2.8 was pretty much hardwired so that Seaside itself wanted to write the HTTP headers into the 
provided socket stream. That doesn't fit our server at all. The server is designed to write the headers and only the 
message payload/body is the responsibility of whatever the application layer is. There are of course mechanisms provided 
to let the app-layer add headers it wants to send, but the actually writing of headers out on the socket is the server's 
job. Moreover Seaside's HTTP writing support is rather simplistic and didn't seem prepared to deal with any of the more 
complex issues, like writing the "quoted" encoding (e.g. ?iso-8859-2?Q?....?, or the base 64 variant ?B?) for non-ascii 
header values, header field folding etc. So the hack we had was really suppressing all that in our server code and 
letting Seaside do its thing, as much as it could. I'm not sure anymore if the problems that lead us to disable 
streaming were due to Seaside's limited HTTP abilities or not.

Either way we hoped to convince the Seaside folks that, rather than doing a bit here and bit there, Seaside should just 
stay away from HTTP writing/parsing as much as it can. So in the streaming mode the desired set of headers should be 
handed over to the server upfront and then there should be a separate call from the server back to Seaside to write just 
the streamed body into a provided socket stream. This may well be the direction that 2.9 already went, I don't know. 
There were more things we wanted to bring up, but I'll have to go back to find out.


Boris Popov wrote:
> Ah, perhaps I misunderstood Michael then, I'll wait for clarification
> from Martin...
> Thanks!
> -Boris

More information about the seaside mailing list