On Tue, 9 Sep 2003, Vadim Gritsenko wrote:
> Sylvain Wallez wrote: > > > Tuomo L wrote: > > > >> It would be convinient, > >> if one could use a protocolthat defines a source (FilePart) located > >> in memory. > >> This could be for example: "multipart://foo.zip" . Then it would > >> be possible to extract that in-memory zip-file to the target-dir. > >> > >> Is this possible already, or am I going to wrong direction here? > > > > You know that you can access files inside zip using jar: protocol, right? This is an example scenario: 1. Client sends a server a request to send some files to another server 2. The first server zips up the files requested (for example with ZipArchiveSerializer) and does a HTTP Post to the second server also running Cocoon (Can be done with a custom action). 3. The second server receives the file, and extracts its contents to a directory defined in sitemap (Custom action here too). 4. The second server then automatically deletes the file. (Cocoon normal behaviour? Seems to me!) So, if the file cannot be reacted on while it is in memory, it's lost. That's why we need that kind of source. (Forget the zip-stuff, it's just an example.) > > > > This is not possible today, but really is the right direction, and > > would be a valuable addition. > > > Wouldn't it be too much strain on system's resources (read: memory) in > production environment (with the exception of light uses like > departamental server) to render this feature useless? I agree though > that it might be actually convinient. Isn't the uploaded file stored in memory at somepoint anyway, and then dumped on disk? After the request/response is complete, the memory is released, right? Question: Is it even possible to react on an uploaded file (if autosave-uploads="true"), if it's deleted right after it arrives? At which point of request/response does Cocoon delete the uploaded file? -Tuomo
