Back to Software Update

The Software Update Manager tracks Updates - current and previously installed.

Requirements

• track current and past updates
• show information on past updates such as time of install, name, etc
• store metadata that allows current updates to be resumed after an application restart
• minimize connection to update server to single connection on initial discovery of update
• remind the user to restart manually stopped updates

Implementation

When an update is stopped or the application is closed, the Software Update Manager stops pending downloads and notes progress so that when the application is started the next time, the download can be restarted at the point it left off.

The Software Update Manager must therefore keep a list of download entries. Each download entry is a collection of one or more patches, containing the same metadata specified in the Software Update:Checking For Updates document. In addition to the metadata specified by that document, the current number of bytes downloaded is also stored.

<?xml version="1.0"?>

<downloads>

 <download type="minor" version="1.0.5" active="true">
   <patch type="partial" url="http://www.foo.com/1.0.4-partial.xpi"
          hashfunction="" hashvalue="" currbytes="44322433" maxbytes="44322433"/>
   <patch type="partial" url="http://www.foo.com/1.0.5-partial.xpi"
          hashfunction="" hashvalue="" currbytes="122443" maxbytes="234234"/>
 </download>

</downloads>

Notes on Attributes

url is the URL the file is being downloaded from, not necessarily the URL the update.xml file specified - this is to prevent hammering a redirector service over and over on retry attempts.

Attributes like hashvalue etc are cached here from the update.xml file so that on subsequent application starts we do not need to reconnect to the Update server to determine these values when the download is complete.

The Software Update Manager looks for the Active Download, then skips to the set of patches whose currbytes attribute is less than their maxbytes attribute, and resumes downloading.

The Software Update Manager uses the nsIIncrementalDownload interface to perform the downloading.

Downloading Files

Patch files are downloaded into the application directory, into this directory structure:

bin/update/patches/1.0.4/patchfile

Service Recording Implementation

A preference can be used to record whether or not we were performing updates during the last application run, and if this value is true, then we can load the update download history file from an XML file in the application directory (rather than the profile - the reason for this should be obvious). The metadata file lives in:

bin/update/updates.xml

This file is the same format as the one used for the remote XML update files except has additional fields for things such as install date etc. It is read into a DOM document which is used to build an in-memory cache of update objects.

A thin nsIRDFDataSource API is layered on top of said cache to provide a way for a front end to show the list of in progress (downloading) and previously installed updates.

Reminders

If the user stops the update manually, the application should remind the user at least once every (update check interval) that the update is not yet complete and should be resumed.

Back to Software Update