Seaside vs Streaming

Here's how I understand current streaming integration in Seaside. If you want the response to "stream" back to the client, the HTTP server has to set the responseStream: on the WARequest object it builds before handing it off to Seaside with the handleRequest: call. If the responseStream is set Seaside will create WAStreamingResponse (instead of WAResponse), which instead of creating an internal stream for the response contents will use the provided one. However since this is expected to be the real socket stream, it will first write complete HTTP header into it on the first access of the #stream. By the time the HTTP server gets control back from #handleRequest: the entire response has already been written into the socket.

Here's what I see as problematic with the above solution:

1) I think the decision to stream or not doesn't belong to the HTTP server. As was previously pointed out, some components must stream, some can work either way and some must not stream. It's the components that know enough to make that decision, not the server. With the current setup, the best you can get is a global flag for streaming on the server which will either force all components to stream or all components to not stream.

2) IMO having the WAStreamingResponse write the header breaks the separation of concerns between the HTTP server and Seaside. The HTTP server may want to add fields, filter others, what not. Moreover the server may want to package the response differently, multipart message rather than a simple body, etc. Nothing like that is possible with the current setup.

Here's what I'd like to have as the integration hooks in Seaside. Leave the decision about streaming to the component. If the component doesn't want to stream it can return WAResponse with the header dictionary and a body stream as before. If the component does want to stream it will return a WAStreamingResponse with header dictionary and a block. The block will take a stream to write the body into as an argument and will be invoked some time later when the time to write the body into the socket comes. If a server cannot stream it can simply invoke the block with an internal stream and then proceed as with regular WAResponse.

For backward compatibility we could still support the responseStream: mechanism. If the responseStream is set, Seaside can just write the headers into it as before and then invoke the body block with the Stream. If the response is non-streaming, we can still just make it write into the provided stream.

That's it.

Now my proposal clearly goes beyond just addressing the two issues mentioned above. It's what I think I'd like to have. However here are some key points that I think are necessary.

1) Components decide about streaming, not the server. Implementing this should be pretty easy, have separate hierarchies for streaming and non-streaming components, or have a flag somewhere, etc. A component could even decide dynamically and stream in some cases and not stream in others.
2) Header fields are *always* provided separately and not written by Seaside
3) The streaming action writes just the body of the response

Does any of this sound reasonable ?

Cheers,

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

Hi Martin,

Maybe it will help you a read of Swazoo streaming approach
http://www.swazoo.org/streaming.html. It would be just nice if we
harmonize streaming approaches at API level, so that porting efforts
will be easier.

Best regards
Janko

Martin Kobetic wrote:

--
Janko Mivšek
AIDA/Web
Smalltalk Web Application Server
http://www.aidaweb.si
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Hi Janko,

Janko Mivšek wrote:
> Maybe it will help you a read of Swazoo streaming approach
> http://www.swazoo.org/streaming.html. It would be just nice if we
> harmonize streaming approaches at API level, so that porting efforts
> will be easier.

OK, I see two separate topics here. One, does the Seaside integration proposal fit your API ? I think it does. Based on your description on the page. I'd expect the streaming hookup to look something like


        waRequest := anHTTPRequest asWARequest.
        waResponse := (WADispatcher default handlerForRequest: waRequest) handleRequest: waRequest.
        waResponse isStreaming
                ifTrue: [ response := anHTTPRequest streamedResponse.
                        self addHeadersFrom: waResponse to: response.
                        waResponse bodyBlock value: response.
                        response close ]
                ifFalse: [ "the non-streaming" case ]


As far as harmonizing our streaming APIs, I'm not sure how far we can get there, given the differences between Swazoo and Opentalk. But here's where I'd like to go with this on the Opentalk side. It's actually more about our streaming rewrite of the core HTTP framework than with Opentalk itself. The framework now handles all the various encoding aspects and their combinations by stacking different kinds of streams on top of each other. Chunking is just another layer in that stack. So far, when you build an HttpResponse, you can give it contents as Strings or ByteArrays or as Streams. So typically you'd do something like this given a content stream.

        response := HttpResponse status: '200'.
        ... set headers ...
        response body source: stream

When you go to write the response on a stream (typically a socket stream) the right stack of streams is built on top of the target stream as different parts of the message are being written.

What I'd like to add is allowing body content to be provided as a block taking a stream as an argument. The block will be invoked at the right time with the stream stack as the argument. This probably isn't that exciting in the context of a web server where most responses are simple, but it opens up a possibility to build arbitrarily complex multi-part messages, where some parts can be set up as static Strings, some hooked up to external file streams, some as blocks to be executed and the whole thing will just stream straight into the target stream when the message is finally written. At the same time the writer can choose to apply any combination of transfer-encodings (gzip, chunked, etc) without any impact on the message building code. As for the Opentalk part, it just needs to build the response object appropriately and hand it a socket stream for writing at the right time. So there isn't really much of an API to speak of. You always just build the response object and writ
e it on a stream. The management of the connection is completely outside of that scope. Opentalk manages connections (implements cuncurrency limits,etc), manages request execution (forking worker processes), controls the request pipeline for each connection (making sure responses go out in the same order as requests came in regardless of which finishes executing first, as per the HTTP spec), etc. Anyway, I'm not sure if there are any aspects that we could cooperate on (other than comparing notes, which I certainly don't mind). Do you see anything specific ?

Cheers,

Martin




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

On 8/16/07, Martin Kobetic <[hidden email]> wrote:

> Here's what I'd like to have as the integration hooks in Seaside. Leave the decision about streaming to the component. If the component doesn't want to stream it can return WAResponse with the header dictionary and a body stream as before. If the component does want to stream it will return a WAStreamingResponse with header dictionary and a block. The block will take a stream to write the body into as an argument and will be invoked some time later when the time to write the body into the socket comes. If a server cannot stream it can simply invoke the block with an internal stream and then proceed as with regular WAResponse.

Just to be clear - it is exceptional for a component to return any
sort of response; normally a component is just expected to render a
small piece of HTML to whatever the current response is (or there
might not be one at all, if we're building up HTML on an internal
stream for some purpose).  Returning a response means that a component
is taking over the page and ignoring anything that might have come
before it in the render tree.  Usually this doesn't happen from
components at all (or from their render phases at least), but instead
from some callback that wants to shortcut the usual cycle.

Is your suggestion that streaming be treated as an exceptional thing
rather than part of the standard rendering of a component - so, as a
slightly awkward big gun to pull out when optimization was crucial or
when you wanted a comet-like push interface, rather than as a
transparent framework-wide optimization?  I think that's probably ok
(given that nobody has achieved the latter goal so far), just want to
make sure.

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

Hi Martin,

Martin Kobetic wrote:
Yes, that's actually almost the same as Swazoo approach.Maybe just a line:

        waResponse bodyBlock value: response.

How is that block implemented. Something like:

        [:streamedResponse |
           [elements atEnd] whileFalse:
               [streamedResponse nextPutAll: elements next asHTML] ?


Here Swazoo is a bit different. On output streaming you get a prepared
response for streaming and then you stream directly to that response.
This can be done of course from the block and here we are together again.

But on input streaming (file uploads) you actually provide a streaming
block to Swazoo, which is then called when post data parsing occurs. And
that parsing is deferred (request is not received in full immediately)
until you provide that block. So the framework have a time to decide
what to do with a request - to prepare a file with a right filename on
the right place to stream into, for instance.


> This probably isn't that
> exciting in the context of a web server where most responses are simple,
> but it opens up a possibility to build arbitrarily complex multi-part
> messages, where some parts can be set up as static Strings, some hooked
> up to external file streams, some as blocks to be executed and the whole
> thing will just stream straight into the target stream when the message
> is finally written. At the same time the writer can choose to apply any
> combination of transfer-encodings (gzip, chunked, etc) without any
> impact on the message building code.

This is interesting and I also thought about to go so wide with
functionality, but then I decided that simplicity is Swazoo's first goal
and that a response will stay with only one part. But combinations of
transfer encodings are definitively waiting to be extended at least to
gzip in Swazoo too.

I think that we don't need to harmonize internals of both servers,
because their goals are different. Swazoo goal is portability,
simplicity and performance, while one of Opentalk goals seems to be a
complete implementation of HTTP protocol.

But on API level we are actually similar enough it seems. And
harmonizing don't mean that they need to be equal. And because they are
similar enough, this will definitively help both web servers to be
connected to the frameworks and interchanged at the will, easily.

Best regards
Janko



--
Janko Mivšek
AIDA/Web
Smalltalk Web Application Server
http://www.aidaweb.si
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Avi Bryant wrote:
> Just to be clear - it is exceptional for a component to return any
> sort of response; normally a component is just expected to render a
> small piece of HTML to whatever the current response is (or there
> might not be one at all, if we're building up HTML on an internal
> stream for some purpose).  Returning a response means that a component
> is taking over the page and ignoring anything that might have come
> before it in the render tree.  Usually this doesn't happen from
> components at all (or from their render phases at least), but instead
> from some callback that wants to shortcut the usual cycle.

Most likely my Seaside terminology is off. I don't really know that much about Seaside internals, I'm just looking at it from point of view of the external HTTP server integrating with it. When I said "component returns response", I really meant the #handleRequest: call (or an equivalent) returns a response. But what I see crucial is that the decision to stream or not for that particular response should be made by specific "pieces" (to avoid any Seaside specific terminology here) implemented or used by the web application code. E.g. the author of the Commet support should be able to just set a flag somewhere or subclass the right class or whatever would be most suitable way to express the notion that these "pieces" need to stream the response. How exactly is the decision expressed at that end isn't really my concern as long as the decision is somehow conveyed to the layers building the WAResponses and executed there by giving it a stream or a block. The "block" part of course
 assuming we agree with my proposal. There are other ways to handle the streaming type than using a block, but I wanted to suggest my preference.

> Is your suggestion that streaming be treated as an exceptional thing
> rather than part of the standard rendering of a component - so, as a
> slightly awkward big gun to pull out when optimization was crucial or
> when you wanted a comet-like push interface, rather than as a
> transparent framework-wide optimization?  I think that's probably ok
> (given that nobody has achieved the latter goal so far), just want to
> make sure.

I'm not sure I get this part. I'm just suggesting changes to the way response streaming is currently hooked up to Seaside. I don't view streaming to be "exceptional" and non-streaming to be "normal". Just two functionally different ways to push a response back, each suitable for different purposes. I'm probably oversimplifying the situation somewhat, e.g. it's up for discussion how to handle the cases where some parts of the page require streaming and some not. But hopefully there is a reasonable set of rules that can be set up for these issues. Presumably, in the current situation it will just fail in some (possibly non-obvious) way. Maybe simply returning an error explaining the nature of the problem is actually better than getting a somewhat broken page back. To boil down my set of basic requirements some more, avoiding talk about parts I'm not that familiar with:

1) The decision to stream or not doesn't belong to the HTTP server
2) Seaside shouldn't write HTTP headers directly into the socket, ever.
3) In the streaming case the HTTP server should be able to obtain the response headers from Seaside before handing the socket over to Seaside for the body to be written.

Whatever solution we can come up with that satisfies the 3 points above, works for me.

Does that make it clearer ?

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

Janko Mivšek wrote:
The bodyBlock is something that Seaside would give you to execute with the socket stream as an argument. When the block runs all the Seaside magic happens that eventually produces the characters that should go into the body of the HTTP response. Whatever that is. The block represents the deferred execution of the request by Seaside, to be executed when the socket stream is ready to receive the response body. That's the idea anyway. In the Swazoo case the "socket stream" is represented by your streaming response object. In our case it will be the stream stack we prepare for the body.

> But on input streaming (file uploads) you actually provide a streaming
> block to Swazoo, which is then called when post data parsing occurs. And
> that parsing is deferred (request is not received in full immediately)
> until you provide that block. So the framework have a time to decide
> what to do with a request - to prepare a file with a right filename on
> the right place to stream into, for instance.

That however is processing of the incoming request. That's different "streaming" from what I'm discussing here. You can do input streaming and still not stream the response. In that case you're not really "streaming" in the sense that the web folks care about. AFAIU they really mean the response streaming when they talk about "streaming".

> I think that we don't need to harmonize internals of both servers,
> because their goals are different. Swazoo goal is portability,
> simplicity and performance, while one of Opentalk goals seems to be a
> complete implementation of HTTP protocol.
>
> But on API level we are actually similar enough it seems. And
> harmonizing don't mean that they need to be equal. And because they are
> similar enough, this will definitively help both web servers to be
> connected to the frameworks and interchanged at the will, easily.

Yup, that's why I wanted to discuss this here. I hope that any Kom folks out there will find the time to think about my proposal and chime in too. It seems to me that the current "all or nothing" approach to streaming isn't ideal even from the Seaside point of view, so hopefully there's enough motivation all around to think about ways to improve it.

Cheers,

Martin


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

On Aug 16, 2007, at 11:36 AM, Martin Kobetic 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.

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.

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.

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.

2) Is there a fundamental reason for this, or is it just a quirk of  
the way Opentalk HTTP is implemented? 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?

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?

Colin



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

2007/8/19, Colin Putney <[hidden email]>:
Since when are WATask and handling of errors during the rendering
phase or http basic authentication special cases? Given all the
breakage http response streaming introduces it should be default off
IMHO.

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

On Aug 19, 2007, at 2:07 AM, Philippe Marschall wrote:

> Since when are WATask and handling of errors during the rendering
> phase or http basic authentication special cases? Given all the
> breakage http response streaming introduces it should be default off
> IMHO.

Well, if streaming introduces breakage, we needn't do it at all. I'm  
assuming that this stuff can be made to work with streaming  
responses. Is there some reason they can't?

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

2007/8/19, Colin Putney <[hidden email]>:
Error handling can never work because you already rendered stuff that
might already be sent.
WATask can not work with the current implementation (redirect in
#renderContentOn:).
WABasicAuthentication would need a completely different implementation
(no longer a global decoration).

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

On Aug 19, 2007, at 3:27 PM, Philippe Marschall wrote:

True, but that doesn't mean errors can't be handled. The default  
error handler might render a walkback half-way down a page that has  
other stuff already rendered. That's not the end of the world for  
development. For deployment, where you might want a custom error  
handler that displayed an error reporter or something, yeah you'd  
have to decide on a tradeoff between streaming and the error reporter.

> WATask can not work with the current implementation (redirect in
> #renderContentOn:).
> WABasicAuthentication would need a completely different implementation
> (no longer a global decoration).

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.

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

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

This is an interesting optimization anyway, streaming server yes or no.

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

WAListener is a streaming server already, so we can easily test and
change certain things to make it work better with the different parts
of Seaside. Later on if all implications are well understood and if
there are workarounds, we can easily change the default server ...

Lukas

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

Philippe Marschall wrote:
> WABasicAuthentication would need a completely different implementation
> (no longer a global decoration).

I would even say that any of the HTTP authentication mechanisms should be the HTTP server responsibility, not Seaside's. The HTTP server does need some back-end hookup that will actually verify the provided credentials, but it should handle all the messaging details. For example NTLM authentication takes several message exchanges.

The verification back-end could be either Seaside directly, or a separate module that both the server and Seaside talk to.

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:
> > WABasicAuthentication would need a completely different implementation
> > (no longer a global decoration).
>
> I would even say that any of the HTTP authentication mechanisms should be the HTTP server responsibility, not Seaside's. The HTTP server does need some back-end hookup that will actually verify the provided credentials, but it should handle all the messaging details. For example NTLM authentication takes several message exchanges.

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.

Cheers
Philippe

> The verification back-end could be either Seaside directly, or a separate module that both the server and Seaside talk to.
>
> Martin
> _______________________________________________
> 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

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

> So it's not about handling large files. It's about being able to
> do new kinds of web programming.

What kind of new web programming?

Seaside supports Comet style HTTP streaming since 11 April 2006, 12:42:50 am.

Lukas

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

Okay, let's simplify this a bit. If streaming were an option on a
session and defaulted to false to keep all the "cool" things like auth
working, that's fine with me, I would turn it on for our application
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? This way those of us
who want to start delivering content to the user agent as soon as it
becomes available can do that, merely as user experience optimization if
nothing else.

Cheers!

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

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

Lukas Renggli wrote:
>> So it's not about handling large files. It's about being able to
>> do new kinds of web programming.
>
> What kind of new web programming?
>
> Seaside supports Comet style HTTP streaming since 11 April 2006, 12:42:50 am.

Yes, I'm not saying Seaside doesn't support streaming at all now. But I find the streaming hooks insufficient and am hoping to improve that. But the way I understood the previous argument there are doubts if it's worth supporting streaming at all.


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