Extension Manager:Sqlite Storage: Difference between revisions

Extension Manager:Sqlite Storage (view source)

Revision as of 13:03, 16 July 2008

752 bytes removed , 16 July 2008

no edit summary

Mossop

canmove, Confirmed users

1,570

edits

@@ Line 78: / Line 78: @@
 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. Add-on properties don't change all that much, mainly state changes which should make this easy to handle.
+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. Add-on properties don't change all that much, mainly state changes which should make this easy to handle. We already have state changed exposed through observer notifications, we can likely reuse/adapt that method.
 ==API==
-The following interface is what the UI would use to display add-on information for both installed, pending and downloading add-ons. These are just rough sketches, many blanks.
+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).
-<pre>
+[[Extension Manager:Sqlite Storage:nsIExtensionManager]]
-interface nsIAddon : nsISupports
-{
-  readonly attribute AString  id;
-  readonly attribute AString  version;
-  readonly attribute AString  name;
-  //... other metadata ...
+[[Extension Manager:Sqlite Storage:nsIAddon]]
-  readonly attribute boolean  isDisabled;
+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.
-  readonly attribute boolean  isBlocklisted;
-  //... other programatically generated items ...
-}
-interface nsIAddonDownload : nsIAddon
-{
-  const unsigned long STATE_DOWNLOADING = 0;
-  // Whatever states we need to represent different points of the install
-  const unsigned long STATE_PENDING_RESTART = 42;
-  readonly attribute nsIURL       xpiURL
-  readonly attribute nsIPrincipal certificate
-  readonly attribute int          state
-  readonly attribute long         progress;
-  readonly attribute long         maxProgress;
-}
-</pre>
-Installed items would be initialised from the database. Requests for things like localized data can be request additional data from the database after the fact.
 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.''
-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.
 =Major Tasks=