Extension Manager:Sqlite Storage: Difference between revisions

The UI uses a template to display items, however it does not use the real extensions.rdf datasource. Instead a dynamic datasource is provided that calculates values for certain attributes:

The addon table contains all known add-ons in all install locations. This is different from the current situation where we only cache data for the add-ons in the install location with the highest priority. This makes various future behaviours possible including using the newest version of an add-on regardless of installLocation, using any of the same add-on based on compatibility/blocklisting etc. We can create a view in the database that returns only the currently active add-ons for the common query cases.

The target_application table is linked to add-ons by addon id and version rather than being a foreign key into the addon table. Since an add-on might be installed with the same version in different installLocations there is no need to duplicate the compatibility information (which should be the same) in the database. Likewise known updates have their targetApplication info here. We could potentially think about caching this information almost permanently such that future installs of a previously installed add-on may not need another compatibility update check.

Note the local_strings table. This is used for the contributors, localizers and other multi-string localized metadata. The type column will be an enumeration of the different types.

''Do we actually need to keep all the targetApplication data? We do currently but all we need for compatibility checks is minVersion and maxVersion and the app (toolkit/firefox). I'm generally in favour of keeping as much data but querying compatibility would be much simpler with the min/maxversion in the addon table''

Currently the UI is purely template based which has meant that plugin and add-on search results have ended up being put into in-memory rdf datasources. Switching away from templates will allow us to break this into a more straightforward approach. We just have one richlistbox per pane in a deck, on startup we create richlistitems for every installed add-on, plugin and search results when available.

For the install and add-on lists we will have to have some kind of notification from the EM backend to the UI to let it know that a change has been made that might require updating the UI.

Interface changes are necessary so that the UI can query for all of the necessary information. The main changes are to nsIExtensionManager and nsIUpdateItem (renamed to nsIAddon).

Installed items would be initialised from the addon table in the database. This gives enough information for internal operations. Accesses to other properties like the localised information will cause additional db queries to find them.

For a pending install/downloading add-on the nsIAddon interface is mostly unfilled, things like the version are unavailable until after the download is complete and the install.rdf read. If they are updates then the id and name and some other information can be prefilled from the original item. This would enable us to reject updates that turn out to not be the id and version expected.

The methods for retrieving addons on nsIExtensionManager pulls items from one or other of the database and install cache. <code>getPendingInstalls</code>, <code>getAvailableUpdates</code> both retrieve from the install cache. <code>getItemList</code> and <code>getItemForID</code> retrieve from the database.