Tuomo L wrote:
On Tue, 9 Sep 2003, Vadim Gritsenko wrote:
Sylvain Wallez wrote:
Tuomo L wrote:You know that you can access files inside zip using jar: protocol, right?
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?
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,
The file is in place before any processing begins (even before actions are executed) and deleted after the full request processing is over. I had assumed you already knew about this -- if not, be sure to see the wiki resources on file uploads (search for "upload" should find at least three). There is an example action and flow snippet for dealing with the uploaded file while you still have access to it. If you are using 2.1, you'll need to read the flow wiki document even if you're not using flow (it gives an action example at the bottom). This begs to get written up in a full-blown doc which I've been planning to do for some time. If you get stuck, write back for more info (users list would probably be better).
If you knew all that and just wanted to propose a shortcut "source" view into uploaded files, I don't see why not. (Sylvain, did you mean it can't be implemented now or hasn't yet been implemented?)
I just said it's not implemented now but would be nice to have. I would love to hide the storage details of the uploaded content (memory, filesystem, whatever) behind a "multipart" protocol.
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects } Orixo, the opensource XML business alliance - http://www.orixo.com
