Necko supports pause and resume for ftp and http. For ftp, we stop the
request, and restart it later. For http we just stop reading data from the
socket. Both ftp and http have the ability to support resuming; they're
not required to, though. However, theres no backend http support.
While you don't have to invent new necko apis, I can tell you in advance
that, given how the protocols are designed, such an api would almost
certainly involve asking necko for a particular url, starting at byte X.
You would then be responsible for appending the data to the existing file.
Taking that into account in the design would probably make things easier
later on.
[Bringing .netlib into the discussion]
Bradley
Bradley Baetz wrote:
I *really* want to see "partial download resume" work. Suppose the
browser crashes and the user is in the middle of a 20mb download. When
the browser startup again, the user should be asked if they wish to
continue the download from where it ended (minus a few bytes/k in case
of corruption).
As Bradley said, FTP has support *right now* to pickup a partial
download. What is needed is persistence (the ability to remember
partial downloads from launch to launch). HTTP needs both resume-ablity
after a cancel and persistence. It probably require 1 1/2 weeks to
implement both.
This would be a nice RFE to any download manager.
Also, I would like also to see download scheduling. It would be nice to
be able to tell the download manager to download something at a specific
time. I am sure that this would be very useful for users that pay
different rates based on the time of day.
Where is this download manager spec?
doug turner
do...@netscape.com
http://www.mozilla.org/xpapps/MachVPlan/Download_Mgr_estimate.html and
http://www.silverstone.net.nz/work/DownloadManager.htm .
Also see the discussion in npm.browser over the past few days, where this
posting is crossposted to.
Mind the followups if we start into necko API stuff.
>
>doug turner
>do...@netscape.com
>
Bradley