[Seaside] WAFileLibrary / Resource Path

[Boris Popov]

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.

-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 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
problems.
> > > It doesn't work. Handling "big" files in Seaside is generally
> > > discouraged. We prefer to leave it to traditional file servers
like
> > > 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
based
> 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
in
> 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
stream
> > >>  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
the
> HTTP level.
> >
> > 1) switch the connection to transient for the request ('Connection:
> close' or 'Keep-Alive: false' header), write the file into the socket
and
> 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
encoding,
> 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
efficiently.
> Of course the server can still just read the stream into memory and
deal
> with it as with any other content, just less efficiently. That's what
I
> 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