[Seaside] WAFileLibrary / Resource Path

[Martin Kobetic]

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