[Seaside] WAFileLibrary / Resource Path

Boris Popov boris at deepcovelabs.com
Tue Aug 14 16:08:26 UTC 2007


That sounds like a great idea, if you have enough hooks to pass streams
around without reading/writing them yourself, you can sidestep the issue
completely and let the HTTP front broker deal with it efficiently, I
like it.

-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 Martin Kobetic
> Sent: Tuesday, August 14, 2007 9:03 AM
> To: Seaside - general discussion
> Subject: Re: [Seaside] WAFileLibrary / Resource Path
> 
> I apologize for quoting Philippe out of context here, but we've been
> looking at the issue of uploading/dowloading large files via Seaside
> recently and my conclusion is that especially for downloading it's not
> really Seaside's problem to handle. It's for the associated HTTP
server to
> worry about. To test that we can stream downloaded files directly into
the
> socket, all I did was add a subclass of WAFileLibrary and overrode
> documentAt:ifAbsent: as follows:
> 
> WAExternalFileLibrary>>documentAt: aFilename ifAbsent: aBlock
> 
> 	| fn |
> 	fn := '.' asFilename construct: aFilename.
> 	^fn exists
> 		ifTrue: [ | mimeType |
> 			mimeType := self mimetypeForFile: aFilename.
> 			WAResponse new
> 				contentType: (mimeType ifNil:
['application/octet-
> stream']);
> 				headerAt: 'Expires' put: 'Thu, 01 Jan
2095
> 12:00:00 GMT';
> 				stream: fn readStream;
> 				yourself ]
> 		ifFalse: [ aBlock value ]
> 
> Ignore the hardwired directory for the moment. With this I could hit
> http://localhost:7777/seaside/go/files/WAExternalFileLibrary/visual.im
and
> the 11M image file was downloaded pretty much instantly with the
browser
> and server on the same host.
> 
> 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 ?
> 
> Thanks,
> 
> Martin
> 
> Philippe Marschall wrote:
> > An other is that serving big files over Seaside is not recommended
and
> we can't tell
> > you where the limit is to the size of files Seaside can serve.
> > Deployment of resources is an issue that needs to be solved at the
> > Smalltalk or version control level.
> _______________________________________________
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside


More information about the Seaside mailing list