commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Courcoux <pe...@courcoux.biz>
Subject Re: [FileUpload] Support for Progress Reporting
Date Fri, 25 Apr 2003 09:18:07 GMT
Martin,

Thanks for your comments. See below ...

On Fri, 2003-04-25 at 05:43, Martin Cooper wrote:
> 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).

This makes sense. I'm sure we can wait.

> 
> > 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 wasn't sure if this was a common usage pattern, but guessed it might
be an issue. 

> 
> 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.

I could extend FileUpload and implement a 'progress reporting'
interface. That way code using the progress reporting could identify and
use the new class. Code using the original class would not be affected.
This is, in fact, what I have done with my Turbine 2.2 implementation
and I am running both progress reported uploads and non-progress
reported uploads in the same application. It seems backwards compatible.

> 
> >
> > 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 have progress reported every 5 seconds or so. The report consists of
the total bytes read at that point in time, and the name of the file
currently being read. I hadn't thought that non-file field uploading
would take sufficient time to read that recording progress would be
necessary. Am I wrong? Is there a use case that I have missed?

> 
> >
> > 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.
> 

Thanks, I'll hold off a little longer.


Regards,

Peter

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


Mime
View raw message