what is the tentative schedule (milestone target) for the d/l manager?
darin
Bradley Baetz wrote:
> 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:
>
> - 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
>
