[Seaside] [VW][7.6] Streaming?

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

Cheers
Philippe

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.
>
>
>  -Boris
>
>  --
>  +1.604.689.0322
>  DeepCove Labs Ltd.
>  4th floor 595 Howe Street
>  Vancouver, Canada V6C 2T5
>  http://tinyurl.com/r7uw4
>
>  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
>  attachments.
>
>  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
>  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.
>  >
>  > Martin
>  >
>  > 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
>  > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>  _______________________________________________
>  seaside mailing list
>  seaside at lists.squeakfoundation.org
>  http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>