[Seaside] [VW][7.6] Streaming?
philippe.marschall at gmail.com
Tue Apr 22 05:44:00 UTC 2008
2008/4/21, Martin Kobetic <mkobetic at cincom.com>:
> 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.
The time to discuss the problem is now. Otherwise once you have time
Seaside 2.9 will be in the same state as Seaside 2.8 and the
functionality will be the same because that's what works for us.
> 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.
That's the implementation that WAListener uses. This is not hardwired
into Seaside. Standard Seaside does no serialization /
de-serialization of headers, not even for cookies, this happens only
in the server adapter. The only exceptions here are:
WABasicAuthentication is bad, I admit that. Caching simply sets ASCII
string key/value pairs, so does #attachmentWithFileName:, I can't see
anything wrong with that. The server adapter does encoding of the
strings like for all the other headers the user might add. The only
potential problem is the encoding of the URL in the redirect. But
Seaside at the moment supports only ASCII urls anyway. So I don't
really see a problem here.
> 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.
Come up with code and we'll sure have a look at it.
> Boris Popov wrote:
> > Ah, perhaps I misunderstood Michael then, I'll wait for clarification
> > from Martin...
> > Thanks!
> > -Boris
> seaside mailing list
> seaside at lists.squeakfoundation.org
More information about the seaside