[Seaside] WAFileLibrary / Resource Path

Boris Popov boris at deepcovelabs.com
Tue Aug 14 19:26:24 UTC 2007

But what would stop servers not capable of 'streaming' from reading the
contents of the stream and serving the same thing with Content-Length?
Surely you'd have a memory hit, but that's why the preference would be
to use a server that supports streaming. I think we might all be talking
about the same thing here and agreeing on it at the same time.


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 Philippe Marschall
> Sent: Tuesday, August 14, 2007 12:24 PM
> To: Seaside - general discussion
> Subject: Re: [Seaside] WAFileLibrary / Resource Path
> 2007/8/14, Martin Kobetic <mkobetic at cincom.com>:
> > Philippe Marschall wrote:
> > > That's true. WAFileLibrary is a simple solution for simple
> > > It doesn't work. Handling "big" files in Seaside is generally
> > > discouraged. We prefer to leave it to traditional file servers
> > > Apache or lighy which are optimized for this task. This also takes
> > > load off your Smalltalk Image.
> >
> > I understand. Actually, we've been recommending the same for VW
> web servers for long time as well.
> > However there were several "streaming server" projects recently with
> quite encouraging results, suggesting that we may be able to push the
> limits of pure Smalltalk servers quite a bit higher than we would dare
> just a few years ago. I certainly don't expect to beat Apache and such
> their game, but a fairly large class of web applications might be just
> fine with pure Smalltalk solution with all its benefits. So I feel
that we
> shouldn't just dismiss the possibility of serving files from Smalltalk
> outright.
> >
> > >> The key is that we build a WAResponse here with an external
> > >>  in it, and the rest is handled by the HTTP server. Am I missing
> > >> something from the bigger picture ?
> > >
> > > Depends on whether you server adaptor supports output streaming.
> >
> > Well, I guess, for some definition of "streaming".
> Your web server accepts a response object who's contents are a stream
> and sends them out over http without fully reading the stream upfront.
> Philippe
> > AFAIK there are following alternatives for handling a large file at
> HTTP level.
> >
> > 1) switch the connection to transient for the request ('Connection:
> close' or 'Keep-Alive: false' header), write the file into the socket
> close the connection.
> >
> > 2) if you can determine the size of the file upfront, which is often
> fairly easy, and if you don't intend to use compressed transfer
> just use the size for the Content-Length header.
> >
> > 3) use chunked transfer encoding (I believe that's HTTP 1.1 only)
> >
> > Any of these would allow you to handle the file reasonably
> Of course the server can still just read the stream into memory and
> with it as with any other content, just less efficiently. That's what
> meant by the "it's up to the HTTP server".
> >
> > Cheers,
> >
> > Martin
> >
> > _______________________________________________
> > Seaside mailing list
> > Seaside at lists.squeakfoundation.org
> > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
> >
> _______________________________________________
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

More information about the Seaside mailing list