Seaside vs Streaming

> anyway since we don't use it. Also, I believe there was some talk about
> making one extra pass over a component tree to try and determine if any
> components would "vote" to suppress streaming for that specific request,
> say if WATask is involved, can we still do that?

Seaside2.8a1-lr.447 and later fully support WATask withing a streaming
server, thanks to the idea of Colin to do the redirect in
#updateRoot:. It seems to work well, but it certainly requires some
deep testing.

I guess that there is nothing that prevents to refactor
WABasicAuthentication exactly the same way ...

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

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

[hidden email]

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: [hidden email] [mailto:seaside-
> [hidden email]] 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, 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
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> - error handling
> - tasks
> - basic authentication
> - anything else?
>
>  
Well as Lukas says - tasks and auth can be handled just fine with
streaming. Error handling, as you said, is a special case. When we did
error handling, we would emit a <script> that would redirect the page to
an error page, avoiding the 'part of the page' problem when reporting
errors.

It certainly seems like progress has already been made in the direction
that Martin was suggesting - at least from what Lukas was saying.

Michael
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> cases and toggle the response mode on a per-request basis? What is the
> exact list so far?
>
> - error handling

It looks ugly, but it sort of works in most cases.

> - tasks
> - basic authentication
> - anything else?

As I wrote, WATask already supports streaming servers and it can
probably be easily fixed for  WABasicAuthentication and
WASessionProtector.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Can we script errors to trash the existing body and insert them there?
Not sure how well this would work for malformed content (open/incomplete
tags etc) though.

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

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.
to
> an error page, avoiding the 'part of the page' problem when reporting
> errors.
>
> It certainly seems like progress has already been made in the
direction
> that Martin was suggesting - at least from what Lukas was saying.
>
> Michael
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Philippe Marschall wrote:
> The cool thing about it is that's it's a simple, portable solution
> that works nice for simple things like WADispatcherEditor. We like
> simple, portable solutions.

That's certainly a worth-while goal :-). I wonder if it isn't deceivingly simple in this case though.
Looking over the WABasicAuthentication with my ignorant eye, it seems it handles the whole auth interaction by itself (seems like another violation of separation of concerns to me, but anyway). So what happens if the HTTP server has basic authentication built in (not the case with Opentalk one yet, btw) ? What is the interaction between the two ? I assume you can turn it off on Seaside in that case, but how does Seaside get at the auth info in that case ?

Cheers,

Martin
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Colin Putney wrote:

> I suspect that the decision to stream or not to stream should be made by
> the session. It's the part of Seaside that coordinates the
> request/response cycle, and it's easily accessible for customization by
> Seaside applications.

Sounds good. I've started poking around in 2.8, I'll try to direct my attention that way

> It seems to me that building a response goes in three phases - headers,
> head tag, and body tag. Components might want to influence the response
> at each phase, but in order for a response to be streamed, the phases
> must be completed in order, and once a phase is complete, it can't be
> modified.

Yup.

> So, the communication between the HTTP server and Seaside should have
> two parts. First, the session gets to specify any headers it wants set,
> including the status line. Then, if appropriate, the session writes the
> content to a stream. In the case of html content, the session will walk
> the component tree to write the head tag, then again to write the body.

Actually, maybe one more step before that, finding the session for a given incoming request. There might be some setup that the HTTP server may want to do before starting request execution, and a lot of the setup information is best associated with the session, e.g. session locale. If that's bundled together with the step of getting the headers, then it may be too late to configure for the header computation.

> To address your requirements:
>
> 1) The decision to stream or not belongs to the session. I think the
> default should be to stream, with non-streamed responses reserved for
> weird special cases.

Sounds good to me. I don't really care which way the default is set, it's just a default.

> 2) Is there a fundamental reason for this, or is it just a quirk of the
> way Opentalk HTTP is implemented?

Well, we have a working version of streaming with Opentalk and Seaside 2.7. WAStreamResponse>>stream was the one place that we simply had to patch up, if we wanted to retain any control over the outgoing response. You can't write any additional header before, because Seaside is going to write the status line, and you can't add any headers after, because it will write the body in one swoop as well. Anyway, my point is it's not that we can't make it work, we could even avoid the override if we give up the response completely, but that would be just too much for me :-). There's a state machine behind every protocol somewhere, how are you supposed to update your state if you don't even know what response went out? Seaside needs to decide if it wants to be an HTTP server or not. This "i'll do a bit of HTTP here and there and you do the rest" just doesn't feel right.

> Either way, I don't think it's a
> problem. Should there perhaps be a ResponseHeaders object that gets
> passed around to specify what gets sent back?

I was thinking to just stick with Seaside's usual theme, a dictionary of header entries. But again, whatever keeps the folks happy as long as we can decipher it somehow.

I should mention that with the current scheme where the field values are strings we actually have to reparse the values to build our HttpResponse properly, so I would prefer something a bit more structured, but we can do without that.

> 3) Yup. The headers phase has to be complete before the next phase can
> begin. I suppose for the non-streaming case, we need to be able to
> interrupt the sending of the content to change the headers - otherwise
> why wouldn't we stream?

That's why I suggested to keep the current style for the non-streaming case. The response has the content stream and the headers, cookies, etc. The streaming case could use the same form, except for the content you'll get a block to invoke later. I'm hoping that would minimize the amount of changes and seems reasonably simple and consistent interface to me.

Martin


_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

2007/8/20, Martin Kobetic <[hidden email]>:
> Philippe Marschall wrote:
> > The cool thing about it is that's it's a simple, portable solution
> > that works nice for simple things like WADispatcherEditor. We like
> > simple, portable solutions.
>
> That's certainly a worth-while goal :-). I wonder if it isn't deceivingly simple in this case though.
> Looking over the WABasicAuthentication with my ignorant eye, it seems it handles the whole auth interaction by itself.

Yes

> (seems like another violation of separation of concerns to me, but anyway).

You could probably argue the same way. You could also argue that way
for doing all the redirects in #updateRoot: (which makes it feel more
like #prepareRequest).

> So what happens if the HTTP server has basic authentication built in (not the case with Opentalk one yet, btw) ?

As I said, simple solution for simple problems. No intention to solve
anything anything beyond that.

Cheers
Philippe
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

2007/8/20, Boris Popov <[hidden email]>:
> Can we script errors to trash the existing body and insert them there?

Yeah. It should be possible to emit a JS that does a redirect.

> Not sure how well this would work for malformed content (open/incomplete
> tags etc) though.

Hard to tell. Probably depends on browser and the exact circumstances
(eg. inside an attribute or not). It the worst case it might not work
at all. It certainly won't work for IE users with ActiveX disabled for
security reasons.

Cheers
Philippe
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside