commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Cooper <>
Subject Re: [FileUpload] Support for Progress Reporting
Date Fri, 25 Apr 2003 04:43:23 GMT

On Thu, 24 Apr 2003, Peter Courcoux wrote:

> Hi,
> I have implemented upload progress reporting for my turbine 2.2
> application. I am about to switch to turbine 2.3 which uses
> commons-fileupload in place of its own upload service.
> Would you have any objections to providing support for this in
> commons-fileupload.

In principle, no. This looks like a worthwhile enhancement. However, we're
in Beta now, and pushing for a 1.0 release Real Soon Now, so I'd prefer to
defer this to a 1.1 release (meaning that it could appear in a nightly
build shortly after a 1.0 release).

> The changes needed would be
> to set a bytesRead property in MultipartStream on each read() from
> stream to buffer operation,
> provide an accessor for bytesRead
> to make the MultipartStream an instance property in FileUpload and to
> provide a synchronized method to return its bytesRead value. Can anyone
> see any threading issues with this?

This would change the usage criteria for a FileUpload instance. Currently,
it is possible to use a single instance to parse multiple simultaneous
uploads. That would not be possible if the MultipartStream was a data

I'm not sure how big a problem that is, but it's certainly a backwards
compatibility issue, so it would be good if we could avoid that.

> provide a method to return the total request size from FileUpload
> provide a method to return the name of the File being read by FileUpload

The name of the file, or the name of the field? If the former, what about
non-file fields?

> I believe that the changes would be backward compatible. There would be
> a small performance impact on incrementing bytesRead but I would propose
> that this is incremented only on a buffer read, as a compromise between
> granularity and performance.
> Comments?
> I can provide patches in due course.

Patches will greatly increase the probability that the changes will
happen. ;-) That said, I would strongly recommend that you don't do any
work on patches until Beta 2 appears, since there are significant changes
in the works to resolve some existing issues.

Martin Cooper

> Regards,
> Peter
> --
> Peter Courcoux <>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message