cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Howard <>
Subject Re: New protocol for in-memory resources
Date Wed, 10 Sep 2003 11:24:49 GMT
Tuomo L wrote:
> 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://" . 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?


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?)


View raw message