[Seaside] Seaside vs Streaming

[Boris Popov]

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?

-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 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
one
> would use?  YouTube.com is a extreme example due to the amount of
traffic,
> 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
each
> phase,
> 	> these problems could be easily overcome. Redirects or 401
status
> codes
> 	> could be set in the headers pass instead of during rendering,
and
> 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
make
> the
> 	> necessary changes for all Seaside features to work with
streaming
> 	> responses, then we may as well not bother trying to support it
at
> 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
server
> can handle direct streaming of files (in both directions) without
explicit
> streaming support in Seaside (if we avoid defeating it with things
like
> 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
is
> yes, we want streaming, then being able to either stream or not for
any
> particular response should yield the best of both, and should suite
most
> 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
> 
>