VisualWorks + WebServers

>> My next obvious question is, when can I take this for a test drive? ;)
>>  
>Well Martin is getting close to being happy with it. He has it running
>against base seaside without a problem - in fact, it runs faster and can
>do some things that you couldn't do before - such as file upload test
>didn't run.

It will probably take a bit more time to be really confident about it, but it seems to be working at this point. At least as far as I can say clicking through the Seaside test pages and visually comparing results with the WTK and Squeak versions.

The SeasideForOpentalk (SfO) package is now automatically replicated into the public repository, so new versions are available as they come. You'll need a recent version of Opentalk-HTTP as well, the parcel from 7.5 or even a recent build won't do (not until first version of SeasideForOpentalk makes it into a build). There is a short package comment showing how to create a server and few other useful bits. This was all tested against Seaside 2.7. It breaks with 2.8 at least on the Status being Integer instead of String issue, possibly elsewhere too. We're focusing on 2.7 at the moment.

As for the current status. The Opentalk server infrastructure, connection management etc, has been used quite a bit, it's been the basis of the newer Wave servers as well. The HTTP layer itself was only used for deployment of WebServices so far, so I suspect it didn't get as heavy beating as some Web applications get. Moreover we've recently overhauled the entire HTTP layer to make it "stream", which provides same really nice advantages, but it's still fairly fresh code nevertheless (released with VW 7.5). So we have yet to see if we're really done with that. However you can already take advantage of some of the improvements. For example the SfO package includes an example WAExternalFileLibrary which allows fetching external files from a Seaside server. The HTTP layer allows to stream the file directly from the disk into the socket, so getting a 15M image file was nearly instant in my tests running the browser and the server on the same host. For uploads the HTTP layer automa
tically streams message parts designated 'content-disposition:attachment' directly into files, however in the Upload test the file gets packaged as 'form-data' instead (at least by Firefox) so it ends up in memory instead. So we'll have to figure out how to control the decision process for which parts end up in files and which ones in memory. But it's really more an API design issue, technically the layer is ready to stream anything anywhere.

On that note I'd like to mention one change that I felt compelled to make. The WAFile class is designed to hold onto its contents as an internal collection (ByteArray, String, whatever). I added a subclass WAFileStream with the same API allowing to hold onto it as a stream. That still allows using purely internal stream, but opens up the possibility to use an external stream as well. This is obviously aimed at being able to stream contents of a file straight from the socket to the disk as the request is being parsed and then provide the WAFile object on top of the new external stream. Would this kind of change be something of interest ? Maybe for the ongoing 2.8 development effort ?

Finally, I should say that we have yet to address what's referred to as "streaming" in the web-app space. To be honest it's still not quite clear to me what specifically it means at the HTTP level. I've heard it being described as the ability of the application code to write directly into the outgoing socket stream, but that still seems to be just an optimization more than a functional requirement to me. I even ran the SeasideAsync tests with SfO and they still seemed to work, even though they supposedly must have the "streaming" capability. I'm told to try Comet next. Anyway, the point is there might be a limitation in SfO that I don't quite grasp yet, so don't be surprised if you run into it :-).

That's all I can think of that might be of interest at this point. Of course we'd welcome any feedback we get.

Thanks,

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

On 7/25/07, Martin Kobetic <[hidden email]> wrote:

> On that note I'd like to mention one change that I felt compelled to make. The WAFile class is designed to hold onto its contents as an internal collection (ByteArray, String, whatever). I added a subclass WAFileStream with the same API allowing to hold onto it as a stream. That still allows using purely internal stream, but opens up the possibility to use an external stream as well. This is obviously aimed at being able to stream contents of a file straight from the socket to the disk as the request is being parsed and then provide the WAFile object on top of the new external stream. Would this kind of change be something of interest ? Maybe for the ongoing 2.8 development effort ?

That's definitely of interest, at least to me.

> Finally, I should say that we have yet to address what's referred to as "streaming" in the web-app space. To be honest it's still not quite clear to me what specifically it means at the HTTP level.

I think what people usually mean is "Transfer-Encoding: Chunked".

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

Avi Bryant wrote:
> I think what people usually mean is "Transfer-Encoding: Chunked".

OK, that would be great, because that means we're done with that too :-). The HTTP layer chunks automatically when the body reaches some pre-configured size.

Thanks,

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

On 7/25/07, Martin Kobetic <[hidden email]> wrote:
> Avi Bryant wrote:
> > I think what people usually mean is "Transfer-Encoding: Chunked".
>
> OK, that would be great, because that means we're done with that too :-). The HTTP layer chunks automatically when the body reaches some pre-configured size.

Well, let me be more specific: what people want is to have the chunks
start to get sent out as the page renders, rather than have the whole
body get chunked up at the end.

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

Avi Bryant wrote:
Great. For the sake of backward-compatibility the change is actually rather trivial.

Smalltalk.Seaside defineClass: #WAFileStream
        superclass: #{Seaside.WAFile}
        indexedType: #none
        private: false
        instanceVariableNames: ''
        classInstanceVariableNames: ''
        imports: ''
        category: 'SeasideForOpentalk'!

Seaside.WAFileStream comment:
'Minor modification of WAFile to hold the contents as stream, to avoid copying and bringing large content into memory unnecessarily.

'!

!Seaside.WAFileStream methodsFor: 'accessing'!

contents

        ^self stream reset; contents!

contents: aByteArray

        self stream: aByteArray readStream!

stream

        ^contents!

stream: aStream

        contents := aStream! !


This may be too trivial, depending on how often do you need to access the contents as #contents, which will make a copy of the contents every time. It might be interesting to try supporting a kind of a dual mode of existence as either the 'contents' or as the 'stream' depending on the accessors being used. However I suspect that to really take advantage of the external streams other parts may need to change to favor the stream accessors, otherwise all streams will quickly get converted to contents and be stuck in memory again.

Cheers,

Martin


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

Avi Bryant wrote:
OK, and why is that important (other than for obvious memory-efficiency reasons) ?

Thanks,

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

Martin,

Because most browsers will start processing chunks as they come in. Say
you get the first chunk that refers to a bunch of .js and .css files;
browser can then start working on getting those in parallel while the
rest of your page is being rendered/sent over to you. Depending on your
page layout, some will even attempt to do incremental rendering, large
tables and such.

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.
too
> >> :-). The HTTP layer chunks automatically when the body reaches some
> >> pre-configured size.
> >
> > Well, let me be more specific: what people want is to have the
chunks
> > start to get sent out as the page renders, rather than have the
whole
> > body get chunked up at the end.
>
> OK, and why is that important (other than for obvious
memory-efficiency
> reasons) ?
>
> Thanks,
>
> 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

I don't mean to be obtuse, but that still sounds as just an optimization, i.e. nothing would break if the chunking happens after the page is fully rendered. Things just show up a bit later. Or am I missing something ?

It's not that I think this feature is unnecessary, I just like to understand the problem when I try to fix something :-).

Thanks,

Martin

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

>
> OK, and why is that important (other than for obvious
> memory-efficiency reasons) ?
>
> Thanks,
>
> Martin

Because it gives the impression that the site is much faster, the page
starts rendering to the client right away.  

It also allows the server to send down initial content like maybe a splash
page or progress bar, and stream down updates to the UI and then when
finished, hide that and show the result.

Ramon Leon
http://onsmalltalk.com

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

Yes, that's right, the end result of delivering content in full to the
browser is the same, but don't underestimate the important of such
optimization, because every little bit of perceived performance helps
keep users happy :)

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.

> -----Original Message-----
> From: [hidden email] [mailto:seaside-
> [hidden email]] On Behalf Of Martin Kobetic
> Sent: Wednesday, July 25, 2007 12:33 PM
> To: Seaside - general discussion
> Subject: Re: [Seaside] VisualWorks + WebServers
>
> I don't mean to be obtuse, but that still sounds as just an
optimization,
> i.e. nothing would break if the chunking happens after the page is
fully Say
> > you get the first chunk that refers to a bunch of .js and .css
files;
> > browser can then start working on getting those in parallel while
the
> > rest of your page is being rendered/sent over to you. Depending on
your
> > page layout, some will even attempt to do incremental rendering,
large _______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

OK, so the key here is that it's not a single fully rendered page per HTTP response, but rather a sequence of several "UI artifacts" (for lack of better expression) packaged in a single response where you need to previous one to be rendered before the next one arrives. Is that getting close ?

Thanks,

Martin

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

Not quite sure if I'm reading you correctly. Basically you can take one
large page, render it with Content-Length and send it to the browser.
Or, you could get your hands on a stream and start writing to it, which
would in turn start sending chunks of size X to the browser as they are
filling up. Then when you're done with the page, last chunk of size 0
gets sent and browser knows it's the end of it. The key here is that
browser can start working on processing chunks as they arrive before
later parts of the page even finish rendering on the server.

Hope this helps,

-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 Martin Kobetic
> Sent: Wednesday, July 25, 2007 12:37 PM
> To: Seaside - general discussion
> Subject: Re: [Seaside] VisualWorks + WebServers
>
> OK, so the key here is that it's not a single fully rendered page per
HTTP
> response, but rather a sequence of several "UI artifacts" (for lack of
> better expression) packaged in a single response where you need to
> previous one to be rendered before the next one arrives. Is that
getting
> close ?
>
> Thanks,
>
> Martin
>
> Ramon Leon wrote:
> > Because it gives the impression that the site is much faster, the
page
> > starts rendering to the client right away.
> >
> > It also allows the server to send down initial content like maybe a
> splash
> > page or progress bar, and stream down updates to the UI and then
when _______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

2007/7/25, Avi Bryant <[hidden email]>:
> On 7/25/07, Martin Kobetic <[hidden email]> wrote:
> > Avi Bryant wrote:
> > > I think what people usually mean is "Transfer-Encoding: Chunked".
> >
> > OK, that would be great, because that means we're done with that too :-). The HTTP layer chunks automatically when the body reaches some pre-configured size.
>
> Well, let me be more specific: what people want is to have the chunks
> start to get sent out as the page renders, rather than have the whole
> body get chunked up at the end.

Like WAListener? It breaks tasks, WABasicAuthentication and
#returnResponse: but that's something most people are willing to pay.

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

On 7/25/07, Martin Kobetic <[hidden email]> wrote:
> Avi Bryant wrote:

> OK, and why is that important (other than for obvious memory-efficiency reasons) ?

Because it improves perceived performance - the browser can start
rendering the start of the page as it gets the first chunks, which for
large enough pages can be significantly before the last chunks.

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

Philippe,

Would you mind clarifying in what ways it breaks tasks and
#returnResponse: please? I use the following quite a bit, but can't
quite think how incremental chunking would affect the functionality,

self session returnResponse: (WADocumentHandler
                               document: bytes
                               mimeType: mime
                               fileName: filename) response

Thanks!

-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.
Chunked".
> > >
> > > OK, that would be great, because that means we're done with that
too
> :-). The HTTP layer chunks automatically when the body reaches some
pre-
> configured size.
> >
> > Well, let me be more specific: what people want is to have the
chunks
> > start to get sent out as the page renders, rather than have the
whole _______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

2007/7/25, Boris Popov <[hidden email]>:
That's no problem if you use that in the callback phase. If you use
that in the rendering phase like WATask well, you probably already
have done some rendering before this and in the worst case this has
already been sent to the client because you are in streaming mode.
There is no way of undoing this.

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

Ah, yes, there's no way to change your mind in the middle of rendering
if you're streaming, but I imagine most could live without and then we
could think of a way to toggle streaming mode on/off for those
exceptions that will come up. My uses of return response are all within
callbacks for csv/pdf downloads and such, so that's no problem at all,
cool.

Thanks!

-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.
Marschall that
> > too
> > > :-). The HTTP layer chunks automatically when the body reaches
some pay. _______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> OK, so the key here is that it's not a single fully rendered
> page per HTTP response, but rather a sequence of several "UI
> artifacts" (for lack of better expression) packaged in a
> single response where you need to previous one to be rendered
> before the next one arrives. Is that getting close ?
>
> Thanks,
>
> Martin

Basically.  A splash page is a good example, you stream out something to
show the user (makes him think site is fast because it responds so quickly),
and then maybe do a search or something that takes a bit longer.  When you
get results, you stream them out and then some JavaScript that hits the
client and does the transition from splash page to content.

If you know something's going to take a while (say 5 seconds) and you know
you don't want to let the user sitting for more than 2, then you can take
advantage of a streaming server in ways that are hard to fake otherwise
without messing up the back button.  To do such a splash page without a
streaming server requires rendering the splash page first, and then having
some JavaScript post back to the next step.  It looks about the same but
breaks the back button, which now goes into a loop as you go back to a
splash page that submits instead of the previous page.

Streaming servers are really nice to have.

Ramon Leon
http://onsmalltalk.com

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