commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 25830] - Upload Progress Reporting
Date Mon, 02 Feb 2004 14:46:27 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25830>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=25830

Upload Progress Reporting

Brian.Ewins@btinternet.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Upload Progress Reporting   |Upload Progress Reporting



------- Additional Comments From Brian.Ewins@btinternet.com  2004-02-02 14:46 -------
I came in to vote for this one, but there's a number of problems with
DefaultFileUploadProgressReporter.

You don't need to synchronize simple assignments to objects (like the filename -
see JLS sec. 17). In fact it seems like the properties are being stored
internally as Integer mainly to support synchronized(), which is unnecessary -
an int assignment from another int is atomic. The only operation that may need
synchronized is the increment operation. However since this will only ever
contain either the value before the increment, or the value after the increment,
(not some mix of bits) and updates only ever happen in one thread, is there
really a need for this?

Also, it would be useful if DefaultFileUploadProgressReporter implemented
Serializable, so it can be safely stored in a HttpSession - a typical usage
scenario in other 'progress bar' implementations is to pop up a refreshing page
showing the progress from info in the session. 

On the interface, another useful feature would be to have a "java.util.Date
getStartTime()" method - so that elapsed time, est time remaining can be
calculated (we've had people uploading 170Mb docs...I know thats dumb, but they
need to be told its going to take the rest of their lives). 

Finally, the javadoc for the interface should specify what getRequestSize()
returns when its unknown (eg for chunked encoding) - 0? -1?. Supplying
Content-length is only "encouraged" in the file upload rfc.

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