Resuming downloads
Bradley Baetz
discussion)
I've come up with a rough API idea I'd like feedback on. Basically, there
are several things which have to be taken into account:
- Not all protocols support resuming downloads
- Just because the protocol does, doesn't mean that the server does
- If a file changes on the server before resuming the download, let teh
user know. They can then have the option of:
a) restarting from scratch
b) resuming anyway (eg if they're downloading a log file, or something)
c) something else?
(Actually offering these choices are left to the front end, but the back
end needs to be able to support them)
- Its not always possible to get info ona file without starting to
download it (http HEAD isn't really reliable, since some servers always
return a 400 response)
- Different protocols have different ideas of how we can know if a file
has changed - ftp really only has size and last modified, http has entity
tags as well
Note that I only intend to do this for ftp, but want somethign that will,
in tehory, work with http as well.
So, this is what I have as an idea:
interface nsIRestartableChannel : nsIChannel {
/**
* Open this channel, and read starting at the specified offset.
*/
void asyncOpenAt(in nsIStreamListener listener, in nsISupports ctxt,
in long startPos);
/**
* At the onStartRequest, this holds information about the file
* XXX - does this need to be on the nsIRequest. All networking
* protocol's nsIRequest into OnStart are QIable to the channel..
*/
readonly attribute nsIFileInfo info;
}
interface nsIFileInfo : nsISupports {
/** Size of the file, -1 if unknown */
readonly attribute long size;
/** Last modified time, in seconds since epoch */
readonly attribute long lastModified;
/** Entity, may be empty. This is meant to hold the E-Tag for http */
readonly attribute string entity;
// A generic, protocol specific, nsISupports attribute?
}
In the OnStart, a consumer can get the fileInfo, and compare to a
previously stored one (I may make the fileinfo implement nsISerializable -
not sure if its worth it). If they don't want it, they can Cancel the
request, and start again. This is possibly suboptimal from the necko
POV.
Another option is to have AsyncOpenAt take an nsIFileInfo param. If they
don't match, then necko returns an error in the OnStart. If the user wants
to d/l the file from that offset anyway (by checking the attribute on the
nsIResumableChannel, then the consumer calls AsyncOpenAt with a null
nsIFileInfo, meaning "anything goes".
If a file can't be resumed (and offset != 0), then onStart returns a
different error code (NS_ERROR_CANNOT_RESUME). Maybe we should somehow
expose a "Currently, this can be resumed" boolean attribute so that the
d/l manager can warn the user? Or maybe always reutrn an error, even if
offset ==0, and require the user to use AsyncOpen instead, in that case.
It wouldn't be 100% accurate, though, which could be worrying. A consumer
must not cache isResumable accross sessions, since a server could be
updated/config changed/etc.
Comments?
Bradley
Bradley Baetz
>This has come up on npm.browser recently (as part of the download manager
>discussion)
>
>I've come up with a rough API idea I'd like feedback on. Basically, there
>are several things which have to be taken into account:
>
<snip>
Oh, one more thing - cache interaction. I don't know if our cache system
handles partial downloads, but I suggest that anything using this new
interface should not use the cache. Theres no point in having large
downloads there, really, since the dl manager is saving to disk, anyway.
Or maybe it should be made a load flag - DONT_CACHE_ME.
Bradley
Juan Tamad
> - If a file changes on the server before resuming the download, let teh
> user know. They can then have the option of:
> a) restarting from scratch
I think this is the most logical especially if you want to maybe chop
the file into sections like most download managers do to speed things
up, but of course always ask the user
--
Roderick Lazaro :)
Darin Fisher
darin
Bradley Baetz
>what is the tentative schedule (milestone target) for the d/l manager?
>
>darin
>
http://bugzilla.mozilla.org/show_bug.cgi?id=102477 (and related)
0.9.6 - ben's been checking stuff into xpfe/components/download-manager/
The first plan will be without resuming, although if the backend is there
I guess we can convince the front end to be modified without much effort.
Bradley