commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Cooper <mart...@apache.org>
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
member.

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 <peter@courcoux.biz>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message