[Seaside] [VW][7.6] Streaming?
philippe.marschall at gmail.com
Tue Apr 22 05:21:35 UTC 2008
Well there are of course conceptual issues streaming that are
implementation independent. Once a part of the response was been
committed, you can not make up your mind and return something else.
This is especially a problem in the rendering phase. This might seem
strange but there are some interesting uses for this like WATask.
Something like per-component error handlers simply can not work with a
streaming server. We had to hack several places to move the
#returnResponse: from #renderContentOn: to #updateRoot:.
2008/4/21, Boris Popov <boris at deepcovelabs.com>:
> I appreciate the feedback Martin, the reason I brought it up is because
> I upgraded to the latest-and-greatest 7.6 last week and ported to
> Opentalk-Seaside at the same time. Figured might as well look into
> streaming as there was some talk about it back when the project was
> announced. I am not particularly missing anything given that we were on
> a non-streaming server before, but it's certainly something I wouldn't
> mind having if it were offered.
> DeepCove Labs Ltd.
> 4th floor 595 Howe Street
> Vancouver, Canada V6C 2T5
> boris at deepcovelabs.com
> CONFIDENTIALITY NOTICE
> This email is intended only for the persons named in the message
> header. Unless otherwise indicated, it contains information that is
> private and confidential. If you have received it in error, please
> notify the sender and delete the entire message including any
> Thank you.
> > -----Original Message-----
> > From: seaside-bounces at lists.squeakfoundation.org [mailto:seaside-
> > bounces at lists.squeakfoundation.org] On Behalf Of Martin Kobetic
> > Sent: Monday, April 21, 2008 2:18 PM
> > To: Seaside - general discussion
> > Subject: Re: [Seaside] [VW][7.6] Streaming?
> > 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
> > in August last year, Seaside 2.8 was nearing
> > its release and it was quite late for any disruptive changes. So we
> > to just hack our way through the problem and
> > came up with an integration solution that we didn't like but seemed to
> > 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
> > 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
> > 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
> > a bit here and bit there, Seaside should just
> > stay away from HTTP writing/parsing as much as it can. So in the
> > mode the desired set of headers should be
> > handed over to the server upfront and then there should be a separate
> > 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
> > find out.
> > Martin
> > Boris Popov wrote:
> > > Ah, perhaps I misunderstood Michael then, I'll wait for
> > > from Martin...
> > >
> > > Thanks!
> > >
> > > -Boris
> > >
> > _______________________________________________
> > seaside mailing list
> > seaside at lists.squeakfoundation.org
> > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
> seaside mailing list
> seaside at lists.squeakfoundation.org
More information about the seaside