[email protected] wrote:
[snip]
I was curious about the negative adjustment during abort, as that seems
to have confused many people recently. Is what happens the following:
1) We start downloading a (large) file, lets say 100MB
2) We periodically update the progress tracker to report that we've
downloaded bits of the file
3) Then when the connection timesout/aborts/etc (at say 56MB through the
download), we subtract 56MB from the progress tracker?
It makes perfect sense to me why it's done this way, except that if I'm
a user, seeing the amount of stuff I've downloaded go down would confuse
me. Is there a way we could either change the output, or possibly resume
the download in place (at 56MB rather than starting from scratch)?
Its current implementation makes sense to me; since we attempted a
download and then failed, we haven't made the progress towards our goal
that we intended to make.
I guess there are two different ways of tracking progress. The first is
the way we currently do it: We have a overall goal and the number we
report is our progress towards that overall goal. The other way is to
simply report the total amount of bytes we've downloaded, irrespective
of the progress.
I'd use the car trip analogy to think of these numbers.
Say that you're driving from Seattle to San Francisco. The total trip
is 810 miles. You stop and spend the night in Medford, OR. On the
second day of your trip you realize once you've gotten to Redding, CA
that you accidentally left a piece of your luggage back at the hotel.
You've got to drive all the way back to Medford, a 150 mile trip, to
retrieve your bag. Once you're back in Medford the following things are
true: A) You still have to drive 360 miles to get to San Francisco. B)
You've driven 600 miles. When you get to San Francisco, you'll have
reached your goal of traveling 810 miles from your destination, but you
had to actually drive 1110 miles because of an error.
If we're going to report a goal, I'd say that we continue to report
progress as we currently do. Otherwise, the user will end up with 250mb
out of 100mb, which is just as confusing as seeing the counter go
backwards. If we're okay with not reporting a goal, and want to dumb
down the interface so users always see the number go up, we can just
report the number of overall bytes that have been downloaded so far.
I think both of these are beyond the scope of my current change,
however. If you'd like to see a different approach taken, please file a
RFE.
Sure, I didn't mean for you to fix that here, I was asking a more
general question.
Roughly, that question is, "when I download stuff using a web browser
(or other download program I can think of at the moment), progress is
monotonic, why isn't ours?" Now, the answer could be a) they don't retry
so if they time out, they just give up b) they change the goal (though
I've never seen them do that) c) they don't update if they're restarting
from scratch until they've passed what they've reported before or d)
they use the range header to resume downloads where they left off, if
the problem was only a timeout.
And maybe we're only seeing this practically because of the timeout bug
that's been fixed, and once that gets out to people, they're very
unlikely to actually encounter this behavior, in which case I don't care
much.
In any case, I'll file a RFE to resume downloading a partial file using
the range header as that might still be useful for people who are on
thin pipes and have bandwidth restrictions. Sound reasonable?
Brock
-j
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
