AUS:Manual
Contents
Overview
The Application Update Service (AUS) refers to the part of Software Update that tells clients:
- if they have an update
- information about that update if it exists
In general, the transaction looks like:
- Software Update checks app.update.url, passing information about itself
- AUS responds with a properly formed XML document
- Software Update processes that XML document and performs the appropriate task
The general workflow is illustrated below:
Client Settings
Every client passes information to AUS through query string variables. This section breaks down each of these variables and explains its relation to the update service.
As an example, see the app.update.url value taken from Firefox 2.0.0.1 (split up to be readable):
https://aus2.mozilla.org/update /2 /%PRODUCT% /%VERSION% /%BUILD_ID% /%BUILD_TARGET% /%LOCALE% /%CHANNEL% /%OS_VERSION% /update.xml
Incoming URIs
A request from an actual Firefox 2.0.0.2 nightly client on an Intel Mac would look like this:
https://aus2.mozilla.org/update /2 /Firefox /2.0.0.2pre /2007012207 /Darwin_Universal-gcc3 /en-US /nightly /Darwin%208.8.1 /update.xml
This URI is processed by Apache, which rewrites it to a PHP script that is responsible for finding update information based on passed client information. It then proceeds down the workflow illustrated above.
Update Version
/2
Update version was created during the infancy of AUS 2 in order to allow for inevitable changes in:
- the order or format of app.update.url pref
- future additional client information that may need to be processed
- other changes to the point-of-entry for Software Update
Initially, as one might expect, this was 0. 0 was never used in production. For reference, 0 URL looked like:
https://aus2.mozilla.org/update /0 /%PRODUCT% /%VERSION% /%BUILD_ID% /%BUILD_TARGET% /%LOCALE% /update.xml
1 was used in production up until Firefox 2.0. Here is an example:
https://aus2.mozilla.org/update /1 /%PRODUCT% /%VERSION% /%BUILD_ID% /%BUILD_TARGET% /%LOCALE% /%CHANNEL% /update.xml
2 is in use for Firefox 2.0 and above until another iteration is required. Here is an example:
https://aus2.mozilla.org/update /2 /%PRODUCT% /%VERSION% /%BUILD_ID% /%BUILD_TARGET% /%LOCALE% /%CHANNEL% /%OS_VERSION% /update.xml
Product
/Firefox
The product is straightforward. It tells AUS where to look for update information in its data source.
This is typically the name of the product with the first letter capitalized.
Version
/2.0.0.2pre
This specifies which version of our product is requesting an update. For releases, there is a 1:1 relationship between the incoming version and the data source for that version.
For nightlies, product versions are mapped onto branches. Updates for all versions for that branch are determined by looking at the same data set. The %CHANNEL% has to be "nightly" in order to trigger this logic. For example, an incoming version could be 1.5.0.2, but the update would come from the 1.5.0.x source directory.
Versions will pretty much always be similar to versions found in a given product's releases/ directory.
Build
/2007012207
Build id's date the client. Originally AUS was designed to only offer updates to clients who had build IDs that were older than the "latest" update available to AUS.
This was changed when Firefox 2.0 was released, because in order to update 1.5.0.9 clients to 2.0 this rule had to be broken -- the release build for 1.5.0.9 was newer than the release build for 2.0. See bug 357892.
The logic was then limited to non-release channels (nightly channels). Currently the build id is used solely to make sure that nightly testers are always updated to the latest build. It is used to compare the latest available update with what the client currently is, and offers the update only if the available update is newer.
Platform
/Darwin_Universal-gcc3
Platform is straightforward like product is. Once product and version is determined, the platform is needed to specify where to find update information for any given client. There is no additional logic attached to the platform value.
Locale
/en-US
Locale is straightforward. There is no additional logic attached to it.
Channel
/nightly /release
Channel was added with update version 1. Above all, it is used to separate releases from the rest of AUS.
Some other channel examples:
/betatest /releasetest
In addition to making sure official releases are identified by the "release" channel, they also provide a way to test Software Update prior to releases. By using the "betatest" and "releasetest" channels, we can stage updates and verify that they work properly.
A special channel is the "nightly" channel. This triggers all nightly logic. Nightly logic is special because it tells AUS to offer only the latest nightly build to the requesting client.
