RE: File upload progress

2009/6/9 Mike Wilson <mikewse@...>

Lance wrote:

2009/6/7 Mike Wilson <mikewse@...>

Lance wrote:  

dwr.engine.cancelUpload("myUpload");

</javascript>

engine.js generates an invocationId which is passed to the server which can be used to cancel an upload or poll it's current progress.

2) Generic progress and cancellation

As you mentioned in an earlier mail, it could be interesting to provide a generic progress/cancellation mechanism for all calls, not just for file uploads. I then think it would be natural to return an object from any async call following the Deferred/Future pattern. This object could be used for asking about progress, completion status or to trigger cancellation, and would replace (but possibly contain) the invocationId in your example.

If providing progress for all kinds of requests, then we can not depend on always getting a percentage to the progress callback, as we typically don't know the size of outbound data. The parameters could instead be designed this way:

function(transferredBytes, totalBytes)

and the totalBytes would only be set in the cases when we do have that information (and could easily be converted to a percentage). When totalBytes is undefined, a progress dialog could still show the running transferredBytes count.

Hmm... this locks us into a file upload now rather than a more generic process percentage. I'm not 100% on this but could be talked into it. 

My point was actually the opposite, ie not to lock us into file upload ;-).

Normally, it is only at upload (file or data) that we know the total number of bytes we are going to send and can thus calculate the percentage. If we want to use generic progress handling for large sets of outbound data ("download") then we normally don't know the total size at it is processed in a streaming fashion. This makes the percentage impossible to calculate for this case, and therefore I suggested the "transferred byte count so far" to be used in the progress callback.

 

Also, I believe that it could be interesting for the progress indicator to be able, at will, to show the byte count and not just the percentage. Percentages can easily be derived from the bytes if the total is available.

By generic I am talking about for all long running tasks, not necessarily involving bytes. I've seen a really good implementation of a progress indicator where processes were able to return strings stating which stage they were at. A progress manager would after a while collect the results of the same process and would be able to estimate the percentage complete on the current stage and previous results. It's not perfect but the progress widget moved quite steadily after it had collected a big enough survey. Food for thought anyway.  

I think the goal in that previous discussion was to use reverse ajax in streaming mode so updates are transmitted immediately, but within the same request. Ie, a single poll and then pushing progress from the server into the poll request's response stream every 500ms or whatever has been set. This certainly doesn't have to be implemented now, but it would be good if you could take a quick look to see if it will be possible to add this feature within the current public APIs we are designing now.

I must say that my knowlege of how comet works is more theoretical than practical. Can you lead me towards some of the classes you'd like me to take a look at? 

dwr.engine.remote.handleProgress(batchId, progressinfo...)