cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: New protocol for in-memory resources
Date Wed, 10 Sep 2003 14:50:21 GMT
Geoff Howard wrote:

> 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://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,
>
> 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



Mime
View raw message