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

709 bytes removed , 5 October 2015

m

Typo

Jesse

Confirmed users

729

edits

@@ Line 1: / Line 1: @@
 This is a straw-man client implementation plan that covers the main [[Firefox/Go Faster/Client Requirements|Client Requirements]]. The rough set of bugs needed to implement this are called out.
+=Known-good sets=
+To reduce the number of possible configurations thus simplifying QA and dependency issues the client implementation uses the concept of a "known-good set" of system add-ons. This is a list of add-on IDs and versions to run for a particular application.
+Every application package and update will be distributed with a known-good set of system add-ons for that application. Periodically the application will attempt to discover a new known-good set to be installed and used.
+The application will only run with a known-good set of system add-ons enabled or it will not enable any system add-ons and run standalone though since the application ships with a known-good set we should generally never be in this state.
+The only exception is in the case where a developer has installed a version of a system add-on in the profile for testing, in this case it essentially overrides the known-good version for that add-on.
 =Running system add-ons=
@@ Line 7: / 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. When a single build updates to a new version it automatically retains the most recently downloaded system add-ons from the previous version. 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: Create a features install location with a lower priority to the profile location'''
+* '''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: 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 20: / Line 29: @@
 =Discovering system add-ons=
-Already installed system add-ons will use the regular add-on update check mechanism to download and install updates. The existing add-ons manager code should do this automatically.
+By default the add-ons manager will attempt to update system add-ons automatically, this must be disabled so a slightly different mechanism for finding updates can be used.
-* '''Bug: Test that automated updates for the system add-ons location function correctly'''
-During runtime the client will periodically check for system add-ons to use with the current application version. It will do so by making a HTTPS request to a specific URL which will return a root manifest listing the system add-ons for that application, the versions they are compatible with and the URL of a normal [https://developer.mozilla.org/en-US/docs/Extension_Versioning,_Update_and_Compatibility update manifest] for each add-on.
-* '''Bug: Periodically download the system add-ons root manifest'''
-For the returned system add-ons that aren't already installed and that are compatible with the current version of the application the update manifest will be used to find and install the most recent version of that add-on, this re-uses the normal add-on update check code.
+* '''Bug: Disable automated updates for the system add-ons location'''
-* '''Bug: Download and install new system add-ons into the system add-ons install location'''
+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.
-Any currently installed system add-ons that aren't listed as compatible with the current version of the application will be uninstalled.
+An example response:
-* '''Bug: Uninstall system add-ons not listed as compatible with the current application version'''
+ <updates><addons>
+   <addon id="loop@mozilla.org" URL="https://addons.mozilla.org/addons/loop.xpi" version="12"/>
+   <addon id="pdfjs@mozilla.org" URL="https://cdn.addons.mozilla.org/addons/pdfjs.xpi" version="1.4"/>
+ </addons></updates>
-The specific format of the manifest is open for debate but if we want to allow for the same manifest file for multiple client applications and assume that most system add-ons will only be compatible with a single application then something like this would make sense:
+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.
-   "<app-ID>": {
-     "<addon-ID>": {
-       "minVersion": "42.0",
-       "maxVersion": "45.*",
-       "updateManifest": "https://mozilla.com/foo/bar/update.rdf"
-     }
-   }
- }
-There is some duplication of information here. The min/maxVersions are also present in the update manifest but including them in this root manifest allows us to decide what new add-ons need to be installed and which need to be removed without making any secondary requests.
+* '''Bug: Download and install new system add-ons'''
-Here a specific maxVersion is present but we could equally use a maxVersion of "*" (or say that a missing maxVersion property defaults to "*") to say that a system add-on is compatible with all future versions and then change that at a later date.
+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.
-The actual host of the update manifest and the XPIs that it points to doesn't matter to the client code. It could be AMO or something new.
+* '''Bug: Replace the current set of system add-ons with the new known-good set'''
 =Securing system add-ons=
@@ Line 59: / Line 57: @@
 * '''Bug: Add-ons manager signature checks should enforce special rules for add-ons installed in the system add-ons location'''
-The root manifest and update manifests should be protected by https at a minimum (no certificate overrides allowed). As they can only point to signed XPIs there may be no need to do any additional security here but we should consult with the security team.
 =Bootstrapping=
-In order to give a good experience to users using a new profile or updating after not having used the client in a while the application should ship with all system add-ons currently available for that build. This means including the add-ons in installers, packages, dmgs and the update mars for the application.
+In order to give a good experience to users using a new profile or updating after not having used the client in a while the application should ship with a known-good set of system add-ons for that build. This means including the add-ons in installers, packages, dmgs and the update mars for the application.
 * '''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 and compare them to those in the system add-ons install location. If the add-on doesn't exist in the install location or the version there is older than the shipped version then the shipped version will be copied to the install location.
+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 switch to the shipped known-good set"
+=Add-on Dependencies=
-* '''Bug: On startup with a new application version install any new or updated system add-ons into the system add-on install location"
+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.