WAFileLibrary / Resource Path

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

> XXSession>>developmentResourceURLFor: aResourceName
> "Answers the url for aResourceName for the deployed application"
> ^ ((WAUrl new
> addToPath: WADispatcher default basePath ,
> '/files/YourResourceLibrary/';
> yourself) addToPath: aResourceName) asString
>
> Could do the trick?
>
> cheers,
>
> Sebastian
>
>  

> -----Mensaje original-----
> De: [hidden email]
> [mailto:[hidden email]] En nombre
> de Keith Hodges
> Enviado el: Viernes, 17 de Agosto de 2007 20:43
> Para: Seaside - general discussion
> Asunto: Re: [Seaside] WAFileLibrary / Resource Path
>
> Sebastian Sastre wrote:
> > XXSession>>developmentResourceURLFor: aResourceName
> > "Answers the url for aResourceName for the deployed application"
> > ^ ((WAUrl new
> > addToPath: WADispatcher default basePath ,
> > '/files/YourResourceLibrary/';
> > yourself) addToPath: aResourceName) asString
> >
> > Could do the trick?
> >
> > cheers,
> >
> > Sebastian
> >
> >  
> Dear Sebastian,
>
>     If you have a look in the Seaside28Jetsam package there
> is a simpler way.
> WAFileLibrary defines #baseUrl which you can switch to point
> where you wish.
>
> WAStandardFilesPlus does everything you could want, and there
> is a config entry you can add to your application which
> selects the resource baseUrl.
>
> a) Your subclasses (e.g. MyLibrary) inherits the standard
> files, (so the tool bar and other things still work, but you
> can tweak them if you need to on a per application basis)
> b) You can name your library in #libraryName so as to refer
> to something other than the in image class, ie. a local directory.
> e.g. 'resources'
> c) You can put your resources in methods #myPng, or a local
> directory $imageDir/resources/my.png The file based version
> will be served in preference to the method version. (if you
> are editing or uploading your images there is no need to load
> them into the method).
> d) Everywhere you use the resource you can refer to it like so:
>
> html image url: (MyLibrary / 'my.png')
>
> e) The #resourcesBasePath configuration item, if set, will
> change the #baseUrl to point to some other server if you wish.
>
> with #resourcesBasePath set to:
> http://images.serverfarm.com/sebastian/
> and #libraryName set to 'resources'
>
> (MyLibrary / 'my.png') will generate
> http://images.serverfarm.com/sebastian/resources/my.png
>
> best regards
>
> Keith
>
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside