[Seaside] Seaside vs Streaming

Boris Popov boris at deepcovelabs.com
Mon Aug 20 21:31:39 UTC 2007

Well, any time you are dealing with file uploads/downloads streaming
becomes ever more important, but that's not so much of a problem in the
context of this discussion. So far, it seems we have a handful of cases
where streamed responses should be avoided to preserve existing
functionality, so my question is, can't we automatically detect those
cases and toggle the response mode on a per-request basis? What is the
exact list so far?

- error handling
- tasks
- basic authentication
- anything else?


DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5

boris at deepcovelabs.com


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 Conrad Taylor
> Sent: Monday, August 20, 2007 2:26 PM
> To: Seaside - general discussion
> Subject: Re: [Seaside] Seaside vs Streaming
> Hi Martin, I feel the same about this issue.  Thus, I was wondering,
if I
> was building an application like YouTube.com is Seaside, what approach
> would use?  YouTube.com is a extreme example due to the amount of
> uploads, and downloads.  Hence, I would like to understand it's
> architecture for streaming here in a small and simple that can easily
> scale by adding more VM or other techniques and technologies.
> -Conrad
> On 8/20/07, Martin Kobetic <mkobetic at cincom.com > wrote:
> 	>
> 	> But if the session made a pass over the component tree for
> phase,
> 	> these problems could be easily overcome. Redirects or 401
> codes
> 	> could be set in the headers pass instead of during rendering,
> so no
> 	> big structural changes would be needed.
> 	>
> 	> I'm assuming here that there is some desire to have Seaside do
> 	> streaming, or why would we have the discussion? If we don't
> the
> 	> necessary changes for all Seaside features to work with
> 	> responses, then we may as well not bother trying to support it
> all.
> 	> If it's reserved for a special optimization case, then it will
> never get
> 	> used anyway.
> 	My understanding is, that some of the new hip and cool web
> programming techniques require the streaming hookup. So presumably the
> decision is: do we want Seaside to support those or not. The HTTP
> can handle direct streaming of files (in both directions) without
> streaming support in Seaside (if we avoid defeating it with things
> WAFile>>contents). So it's not about handling large files. It's about
> being able to do new kinds of web programming. Assuming the decision
> yes, we want streaming, then being able to either stream or not for
> particular response should yield the best of both, and should suite
> purposes. So I'm not sure what exactly is the argument here. Does the
> streaming hookup proposed here seem too complicated, compared to the
> benefits?
> 	Martin
> 	_______________________________________________
> 	Seaside mailing list
> 	Seaside at lists.squeakfoundation.org
> 	http://lists.squeakfoundation <http://lists.squeakfoundation>
> .org/cgi-bin/mailman/listinfo/seaside

More information about the seaside mailing list