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

Jump to navigation Jump to search

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

Revision as of 18:30, 23 July 2015

378 bytes added ,  23 July 2015
Re-work discovery to allow for downgrades
(Add note on dependencies)
(Re-work discovery to allow for downgrades)
Line 20: Line 20:
=Discovering system add-ons=
=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'''
* '''Bug: Disable automated updates for the system add-ons location'''


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.
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'''
Here is a proposed root manifest format. It allows for multiple client applications to use the same manifest file but assumes that most system add-ons will only work with a single client application.
 
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: Download and install new system add-ons into the system add-ons install location'''
 
Any currently installed system add-ons that aren't listed as compatible with the current version of the application will be uninstalled.
 
* '''Bug: Uninstall system add-ons not listed as compatible with the current application version'''
 
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:


  {
  {
Line 48: Line 38:
  }
  }


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.
The minVersion and maxVersion here are hints for the client application to help reduce the bandwidth when we know that a given system add-on isn't compatible with the application. minVersion defaults to "0" if missing, maxVersion defaults to "*". Most likely a new system add-on will be added with a defined minVersion for the first supported client version with maxVersion omitted. Later when the add-on reaches end of life the maxVersion property would be added. This keeps the need to modify the root manifest to a minimum, only when a new system add-on is created and when one is retired, more complex compatibility information is supported in the update manifest.
 
If the application version falls in the range then the the update manifest is downloaded and used to find a compatible XPI to install. If the application version doesn't fall in the range then it assumes that there is no compatible XPI available.
 
* '''Bug: Periodically download the system add-ons root manifest'''
 
If there is no compatible XPI available for an installed system add-on then it will be uninstalled.
 
* '''Bug: Uninstall system add-ons when no compatible version exists for the current application version'''
 
If there is a compatible XPI available then it will be downloaded and installed unless that specific add-on version is already installed. Note this differs from normal add-on update where we only download newer versions, here we can also downgrade the system add-on.


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: Download and install compatible system add-ons when no matching version is installed'''


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.
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. Changing the host in the future only requires changing the root manifest, no client changes would be necessary.


=Securing system add-ons=
=Securing system add-ons=
Mossop
canmove, Confirmed users
1,570

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/1086402"

Navigation menu