cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geoff Howard" <coc...@leverageweb.com>
Subject RE: New Temporary upload feature
Date Fri, 31 Jan 2003 03:48:27 GMT
Again, sorry for the delay:

> -----Original Message-----
> From: Nathaniel Alfred [mailto:Alfred.Nathaniel@swx.com]
> Sent: Thursday, January 30, 2003 2:52 AM
> To: cocoon-dev@xml.apache.org
> Subject: RE: New Temporary upload feature
>
> >-----Original Message-----
> >From: Vadim Gritsenko [mailto:vadim.gritsenko@verizon.net]
>
> >
> >Geoff Howard wrote:
> >
> >>1) does this seem like a worthwhile feature, and
> >>
> >I think it makes sense to add feature like this.
> >
>
> Certainly a useful feature but rather than having to choose either/or
> we should have a hybrid solution.  For small upload requests use
> FilePartArray
> to avoid the filesystem overhead, for large one use FilePartFile to
> avoid
> memory exhaustion.

Good feature - I think I remember you bringing it up before.

>
> Just define a new config parameter <max-memory-uploads>.  In
> MultipartParser
> read first into a buffer of that size.  If buffer overflows, make an
> FilePartFile,
> otherwise wrap the buffer it into a FilePartArray.

Ok, I have to take a fresh look at MultipartParser.  That seems reasonable.

>
> autosave-uploads="false" with "max-memory-uploads="0" is then equivalent
> to
> your autosave-uploads="temp".

Ok, I think I see this... to implement, I need to perform my check in
CocoonServlet
whenever autosave-uploads="false".  When all files are under
max-memory-uploads, they
will only be FilePartArrays and no cleanup is needed.  When some are, they
will be
FilePartFiles and will get cleaned up.

I may not be able to implement this all together right now.  If not, I'll
make sure to
make easily forward-compatible choices so that can be added later.
Actually, shoot -
they'd have to go together since "temp" would be deprecated by that
addition.  Ok, I'll
see. I could initially only allow a "0" value for max-memory-uploads...

> >
> >>2) make sure my implementation was acceptable.
> >>
>
> An extra loop over *all* parameters of *all* requests is too high a
> price.
> You should use instead a request attribute with a fixed name.  If set,
> it contains the List of FilePartFile objects to clean up.
>
> For autosave-uploads="false", MultipartParser simple creates/adds to
> that
> list the FilePartFile objects it creates.

Ok, that is also a good suggestion:
1) is it weird to have such an attribute added that is not really meant for
use
outside of this cleanup process?  Will it cause problems for people to
introduce
this when they may have expected that only attributes under their control
get
added to the request?
2) Would it be more useful for MultipartParser to always add such an
attribute with
FilePartxxx entries.  It would be more convenient for actions, etc. dealing
with file
uploads to find them without looping on request parameters (or specifying
the parameter
name).  The extra cost seems minimal.  I'm not sure how I like this,
especially if it
means taking the FilePart objects out of the request as there is now other
code that
relies on that, both cocoon internal and external.

Again, thanks for the feedback,

Geoff


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message