Serving files seems to be very confusing, as there are so many driving forces and requirements. 1. The filename. There are two filenames, the one of the structure and the one of the uploaded file. To me it is not clear which one is preferable to be used? The one of the structure changes when the file is renamed, the other one is determined by the original filename of the upload. 2. The serving. There are two ways to serve files. Serving can either happen using Seaside (the default) or using Apache (which is much more efficient). The two approaches have completely different semantics, in the Seaside case we have full control over the path. The approach with Apache is limited to how Magritte lays out the files to the file-system, however that could be fixed using X-Sendfile, but then requires a non-standard plugin in Apache. 3. The response. In the case Seaside is serving we can set Content-Disposition in the response. Setting it means that browsers downloads the file, even if it could be displayed in the browser window. Maybe there are even more possible dimensions. Anybody has an idea how to consistently resolve these problems? Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Maybe offering FileLibrary and its web interface as part of pier, and not forcing it to be a structure could be a solution? But in this case user rights management that works for structures would be lost. rush http://www.cloud208.com/

Yes, that is possible. It is probably more consistent to use the structure name, because like this one has the possibility to rename. This is essentially already implemented, see the class side of MAExternalFileModel or the PRFileSettings widget to change these properties from the web. The problem with Apache serving is that the directories have to be obfuscated to not loose security. This is not a problem for downloads, but for style-sheets for example that sometimes use relative references to other files. Using X-Sendfile this could be fixed relatively easy, but this is a non-standard Apache module. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

On 19-Apr-09, at 1:18 AM, Lukas Renggli wrote: Ah, I thought I mentioned if you stick "inline" in WAReponse>>attachmentWithFileName: aString self headerAt: 'Content-Disposition' put: 'inline; attachment; filename="', aString, '"' see http://www.ietf.org/rfc/rfc2183.txt Then Safari is happy to show PDF files in the browser, versus downloading -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

I think you've a copy of WikiServer, use the latest one and give it a try. The other issue was the desire for Magritte to hand back the contents of the file to seaside for downloading. This might be fine on a server, but if you attempt to toss a 64MB file on the iPhone you die, well it could apply to a desktop machine if you move 500MB files. The problem is MAExternalFileModel>>urlFor: aRenderingContext ^ self baseUrl isNil ifTrue: [ super urlFor: aRenderingContext ] ifFalse: [ self baseUrl , '/' , (self location reduce: [ :a :b | a , '/' , b ]) , '/' , self filename ] MAFileModel>>urlFor: aContext ^ aContext urlForDocument: self contents mimeType: self mimetype fileName: self filename See the "self contents" In WikiServer I changed that to MAExternalFileModel >>urlFor: aContext ^ self baseUrl isNil ifTrue: [aContext urlForDocument: self mimeType: self mimetype fileName: self filename] ifFalse: [ self baseUrl , '/' , (self location reduce: [ :a :b | a , '/' , b ]) , '/' , self filename ] Other helper methods I had to add were MAExternalFileModel>>asMIMEDocumentType: aMimeType "for text documents we need to return the proper mime type aware document otherwise we get UTF-8 errors but for other document types we want a binary type" self maintype = 'text' ifTrue: [^self readStream asMIMEDocumentType: aMimeType]. ^self readStreamBinary asMIMEDocumentType: aMimeType MAExternalFileModel>>readStreamBinary "We make a StandardFileStream instance and set to binary, oddly someone closes this later and re-opens as text if we make a MultiByteFileStream then it starts streaming as utf-8 which is a bad thing" ^ (self directory readOnlyStandardFileNamed: self filename) binary FileDirectory>>readOnlyStandardFileNamed: localFileName "Open the existing file with the given name in this directory for read-only access." ^ StandardFileStream readOnlyFileNamed: (self fullNameFor: localFileName) On 19-Apr-09, at 11:03 AM, Lukas Renggli wrote: -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

Ok, well I forgot to add the part for the upload side. Again the issue on the iphone is uploading 50MB files, but for desktop, what if someone wants to push 1GB file? anyway first you have to turn on the KOM stream uploading feature, say via WAKom default streamUploads: true. now the issue is with MAFileUploadCompoent>>upload: aFile self value: (aFile isNil ifFalse: [ self description kind new mimetype: aFile contentType; filename: aFile fileName; contents: aFile contents; yourself ]) That sets the content to "aFile contents". I changed that to MAFileUploadComponent>>upload: aFile self value: (aFile isNil ifFalse: [ self description kind new mimetype: aFile contentType; filename: aFile fileName; contentsFromWATemporaryFileProxy: aFile; yourself ]) MAFileModel>>contentsFromWATemporaryFilePRoxy: file self contents: file contents and MAExternalFileModel>>contentsFromWATemporaryFileProxy: file | writeStream readStream | "Write Stream is a file handle to the Pier storage library, Read Stream will be the WATemporaryFile" "Set instance filesave value, and copy file from temporary storage to Pier storage" writeStream := self writeStream. readStream := file stream. filesize := readStream size. [FileDirectory default copyFile: readStream toFile: writeStream] ensure: [readStream close. writeStream close] and WATemporaryFile>>stream | stream | stream := self temporaryDirectory readOnlyFileNamed: self temporaryFileName. stream binary. ^stream I note however on the iPhone I do this instead of the copyFile:toFile: IPhoneWikiServerUI isiPhone ifTrue: [IPhoneWikiServerUI move: readStream to: writeStream. ^self]. and use an operating system call to move the file from one directory to the other so the cost is zero, when WATemporaryFileProxy closes, it runs out the delete the file, but we've move it, guess I should add an override... BTW In Sophie we coded up a os-x api call to either copy or move files via OS calls so we could preserve all the file meta-data. Doing the copyFile: toFile: is just so *primitive* and expensive. Now if someone want's to test all this that would be great because my environment is contaminated with changes and it's a bit hard to confirm I"ve detailed all the changes. We've attempted to mark all our Magrritte/pier/seaside changes as overrides or extensions, but it's easy to miss one or two. Testing in fact is easy on a desktop machine, for linux based machines you would start the VM with a memory configuration of oh say 40MB depending on your pier image. On the Macintosh make a copy of the squeak.app and change the info.plist SqueakMaxHeapSize entry from 536870912 to 40000000, or you can start the VM on the cmd line (see http://wiki.squeak.org/squeak/105) and set -memory 40m just like you would do on Linux. This will limit the VM to use 40MB of memory, now attempt to add an image file of say 50MB to a pier page. No doubt you should use the GC/ memory report to confirm what you think you are telling the VM about memory upper bound is what it actually is don.g On 19-Apr-09, at 2:12 PM, Lukas Renggli wrote: -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

As I tried to explain there are several dragging forces here. When one is fixed, another one breaks. I am trying to find a solution that is consistent and that works for most setups. Earlier versions did not show this bug until John McIntosh discovered that enforcing a file-name in the HTTP header caused the file to always be downloaded instead of displayed inside the browser window. Lukas -- Lukas Renggli http://www.lukas-renggli.ch