You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by bu...@apache.org on 2004/02/02 15:46:27 UTC
DO NOT REPLY [Bug 25830] -
Upload Progress Reporting
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