canmove, Confirmed users
1,570
edits
Extension Manager:Sqlite Storage: Difference between revisions
Jump to navigation
Jump to search
no edit summary
No edit summary |
No edit summary |
||
| Line 73: | Line 73: | ||
The targetApplication table is keyed on addonid and version rather than being a foreign key into the addon table. It should keep targetApplication information for all installLocations, since an add-on might be installed with the same version in different installLocations there is no need to duplicate that information 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. | The targetApplication table is keyed on addonid and version rather than being a foreign key into the addon table. It should keep targetApplication information for all installLocations, since an add-on might be installed with the same version in different installLocations there is no need to duplicate that information 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. | ||
Might want to do the same for the dependencies, however right now they come only out of the install.rdf and are never updated by remote data. | ''Might want to do the same for the dependencies, however right now they come only out of the install.rdf and are never updated by remote data.'' | ||
''Still need to consider what generated properties should be held in the database. We could go with just appDisabled as currently, or we could store blocklisted, compatible and updatesSecurely separately.'' | |||
''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'' | |||
==API== | ==API== | ||
| Line 111: | Line 114: | ||
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. | 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. | ||
We could consider moving the add-on operations (uninstall, disable, enable etc.) onto the nsIAddon interface. | ''We could consider moving the add-on operations (uninstall, disable, enable etc.) onto the nsIAddon interface.'' | ||
The UI (and any other callers) should be able to request the current active (meaning visible, not necessarily enabled) add-ons list, the current available update list and the current installs list from the extension manager. Maybe also the full list of add-ons in all install locations. | The UI (and any other callers) should be able to request the current active (meaning visible, not necessarily enabled) add-ons list, the current available update list and the current installs list from the extension manager. Maybe also the full list of add-ons in all install locations. | ||