Firefox/Go Faster/Client Implementation Plan: Difference between revisions

← Older edit

Firefox/Go Faster/Client Implementation Plan (view source)

Revision as of 18:58, 5 October 2015

352 bytes removed , 5 October 2015

m

Typo

Jesse

Confirmed users

729

edits

@@ Line 17: / Line 17: @@
 They will be installed in a directory used as a regular add-on install location with a lower priority than the profile install location. This allows developers to test out new versions of system add-ons by installing them using the regular add-ons manager.
-The specific path to the install location will be '''<profile>/features/<app path hash>'''. "app path hash" is a simple hash of the client's install directory. This means that if a user is using two different versions of the client application (say a developer version and a release version) with the same profile they will use two different directories for the system add-ons allowing them to be updated independently and retain the known-good set for each build. The majority of users use a single build and so will have just one directory in use.
+Unlike existing add-on install locations system add-ons will be installed in a filename based on both ID and version, <id>_<version>.xpi. This allows multiple versions of the same add-on to be installed at the same time so if a user is running a developer edition and release version they can rely on different known-good sets.
-The hash can be short to avoid causing path length problems and quick to generate. Collisions aren't a big problem, the client will recover gracefully automatically.
+* '''Bug: Cache the known-good set of add-ons on a per-install basis'''
+* '''Bug: Create a features install location with a lower priority to the profile location which lists the current known-good set of add-ons'''
-* '''Bug: Create a features install location with a lower priority to the profile location'''
 * '''Bug: Hide system add-ons in the features location from the add-ons manager UI'''
-If a user uninstalls an old build they will be left with a now useless set of system add-ons. Periodically we should check '''<profile>/features''' for unused directories. We can write the current time to the current location and for any locations that are older than a certain date delete them.
+If a user uninstalls an old build they will be left with a now useless set of system add-ons. Periodically we should check '''<profile>/features''' for unused add-ons. We can update a manifest with the last-used time of the current add-ons and remove ones that haven't been used in a while.
 * '''Bug: Shortly after startup write the current time to the system add-on install location and purge older locations'''
@@ Line 36: / Line 35: @@
 During runtime the client will periodically make a HTTPS request to a specific URL including data on the application channel, version and OS The manifest returned lists the specific system add-ons that should be used with that application.
-An example of the data the manifest must include:
+An example response:
-  {
+  <updates><addons>
-    "<addon-1-ID>": {
+    <addon id="loop@mozilla.org" URL="https://addons.mozilla.org/addons/loop.xpi" version="12"/>
-     "version": "1.2.0",
+    <addon id="pdfjs@mozilla.org" URL="https://cdn.addons.mozilla.org/addons/pdfjs.xpi" version="1.4"/>
-     "xpiURL": "http://mozilla.com/foo/bar/addon1.xpi",
+  </addons></updates>
-     "xpiHash": "sha256:38974658476582645723465802458972345",
-   },
-    "<addon-2-ID>": {
-     "version": "1.0.0",
-     "xpiURL": "http://mozilla.com/foo/bar/addon2.xpi",
-     "xpiHash": "sha256:45676878579689577567674563576746746",
-   }
-  }
-This manifest could be a standalone file or embedded in the existing update.xml file somewhere. The former is a little easier to implement on the client side.
+If the server returns with an error or malformed XML or the response doesn't include an <addons> section then the result is ignored and the current set of system add-ons is kept. If the <addons> tag is present but empty then it means no system add-ons should be enabled.
-Any add-on versions that are not already available locally are downloaded and checked against the given hash (is this needed given that we're signing the add-ons too?).
+Any add-on versions that are not already available locally are downloaded.
 * '''Bug: Download and install new system add-ons'''
-Once all the add-on versions listed in the manifest are available locally this list replaces the current known-good set, any enabled system add-ons not in the set are disabled, any system add-ons in the set not enabled are enabled.
+Once all the add-on versions listed in the manifest are available locally and are verified to be usable with the current application they are copied to a new directory inside <profile>/features and the known-good set is updated with the new set. Any enabled system add-ons not in the set are disabled, any system add-ons in the set not enabled are enabled.
 * '''Bug: Replace the current set of system add-ons with the new known-good set'''
@@ Line 73: / Line 64: @@
 * '''Bug: Include system add-ons in application packages and updates'''
-On the startup of a new version of an application the client will find the add-ons included with the application, copy them to the install location and then use them as the known-good set.
+On the startup of a new version of an application the client will replace its known-good set with the new set included in the application.
-* '''Bug: On startup with a new application version install all bundled system add-ons into the system add-on install location"
+* '''Bug: On startup with a new application version switch to the shipped known-good set"
 =Add-on Dependencies=
 Add-on dependencies should be managed at the server side. The client will ensure that only a known-good set of system add-ons runs.