Firefox/Projects/Extension Manager API: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
 
(23 intermediate revisions by 4 users not shown)
Line 1: Line 1:
= Overview  =
__NOTOC__<section begin=overview />The Extension Manager has been extended repeatedly to add new features. There is now large scope for cleanups and improvements with refactoring the core code and APIs as well as integrating the other add-on types into a unified API that the frontend can use to display the UI.<section end=overview />


;Sprint lead: Mossop
* Project lead: <section begin=lead />Mossop<section end=lead />
;Reviewers: Rob Strong, Shawn Wilsher, Benjamin Smedberg
* Project members: Boriss, Unfocused
* Potential reviewers: sdwilsh, bsmedberg, robstrong
* QA contacts: hskupin (lead), tchung


;Description
=Status=
:The Extension Manager has been extended repeatedly to add new features. There is now large scope for cleanups and improvements with refactoring the core code and APIs knowing what we know now.


= Goals / Use Cases  =
* IN FLIGHT
* Implementation in progress in a user repository
* <onlyinclude>Running performance testing, looks like a minor loss but not unexpected. Going to be getting ready for reviews this week</onlyinclude>


* Primary goals
=Goals=
** Support a wider range of add-on types managed through the same API
** Allow application/extension developers to be able to easily query the state of installed items
** Make it easier for applications to replace the add-ons UI with their own implementation by making all necessary information available through the defined API
* Secondary goals
** Remove direct access to the datastore
** Simplify the internal code and speed up startup times
** Minimize the use of RDF throughout the backend to allow for easy replacement in the future
** Migrate from an RDF based datastore to an SQLite based datastore
** Remove extensions.cache
** Reduce the number of unnecessary restarts during startup


= Design  =
* Replace extensions.rdf with a sqlite based datastore
* Implement a new API for accessing all types of add-ons
* Implement a type of XPI extensions that can be [[Extension Manager:Bootstrapped Extensions|installed without restarting]]
* Create a clean separation between the UI and the backend of the add-ons manager
* Lay the groundwork for supporting different types of install manifests in XPI extensions
* Lay the groundwork that will help us give startup performance improvements
* Reduce the number of unecessary EM restarts


The new API is proposed at [[Extension Manager:API Rewrite]]. Some of this work will assist in the implementation of [[Extension Manager:UI Update]].
=Non-Goals=


= Planning  =
* Improve startup time
* Make current XPI extensions install without restarts


== Target Release ==
=Timeline/Milestones=


Firefox.next. All of the initial work must ship before beta 1.
* 2009/10: [Complete] [[Extension Manager:API Rewrite|API Design]] complete and reviewed
* 2009/12: [Complete] Implementation usable enough for UI work to proceed
* 2010/03: [Complete] Land on a [https://bugzilla.mozilla.org/show_bug.cgi?id=542910 project branch] to monitor performance impact
* 2010/03: [Complete] [[Firefox/Projects/Extension Manager API/Security Overview|Preliminary security review]]
* 2010/03: Test review with QA
* 2010/03: Land on trunk with near feature parity
* 2010/04: Complete feature parity and additional metadata
* 2010/04: Final security review


== Status ==
=Delivery Requirements=


* [22/06/09] - Implemented basic API framework and detection of items that need to be processed during startup.
* Requires an add-on compatibility changing application version increment
* [23/06/09] - Read manifest data from install.rdf and hook the public API up to the backend. Add tests that verify install location priorities and startup detection.
* Requires messaging to add-on and application developers to explain how to switch to the new APIs
* [24/06/09] - Performance improvements and hook app all manifest data in the database. Make public wrappers around internal data and add stubs for the install APIs.
* Must be complete before the first beta of the target delivery vehicle
* [25/06/09] - Hook up installing from xpi files and add an update checker module.
* [30/06/09] - Set up for processing disabling during startup and add checks for application compatibility.
* [03/07/09] - Implement dependency checks and disabling.
* [07/07/09] - Implemented uninstalling. Corrently update dependent items during installs.
* [08/07/09] - Implement theme special cases and switching and add permissions attribute for UI updating.
* [09/07/09] - Wire up most of update checking.


== References ==
=Dependencies=


* {{Bug|461973}}
=Testing=
 
* Majority of tests will be xpcshell based with some mochichrome testing for ssl support.
* Existing add-ons manager unit tests will be replaced, ported or no longer applicable to the new API.
* QA have put together a [[QA/Firefox 3.next/Test Plan:AddonsManagerRedesign|test plan]] for manual testing.
 
=Related Projects=
 
* [[Firefox/Projects/Extension_Manager_Redesign|Extension Manager Redesign]] is the work to replace the frontend add-ons UI

Latest revision as of 20:21, 8 April 2010

The Extension Manager has been extended repeatedly to add new features. There is now large scope for cleanups and improvements with refactoring the core code and APIs as well as integrating the other add-on types into a unified API that the frontend can use to display the UI.

  • Project lead: Mossop
  • Project members: Boriss, Unfocused
  • Potential reviewers: sdwilsh, bsmedberg, robstrong
  • QA contacts: hskupin (lead), tchung

Status

  • IN FLIGHT
  • Implementation in progress in a user repository
  • Running performance testing, looks like a minor loss but not unexpected. Going to be getting ready for reviews this week

Goals

  • Replace extensions.rdf with a sqlite based datastore
  • Implement a new API for accessing all types of add-ons
  • Implement a type of XPI extensions that can be installed without restarting
  • Create a clean separation between the UI and the backend of the add-ons manager
  • Lay the groundwork for supporting different types of install manifests in XPI extensions
  • Lay the groundwork that will help us give startup performance improvements
  • Reduce the number of unecessary EM restarts

Non-Goals

  • Improve startup time
  • Make current XPI extensions install without restarts

Timeline/Milestones

  • 2009/10: [Complete] API Design complete and reviewed
  • 2009/12: [Complete] Implementation usable enough for UI work to proceed
  • 2010/03: [Complete] Land on a project branch to monitor performance impact
  • 2010/03: [Complete] Preliminary security review
  • 2010/03: Test review with QA
  • 2010/03: Land on trunk with near feature parity
  • 2010/04: Complete feature parity and additional metadata
  • 2010/04: Final security review

Delivery Requirements

  • Requires an add-on compatibility changing application version increment
  • Requires messaging to add-on and application developers to explain how to switch to the new APIs
  • Must be complete before the first beta of the target delivery vehicle

Dependencies

Testing

  • Majority of tests will be xpcshell based with some mochichrome testing for ssl support.
  • Existing add-ons manager unit tests will be replaced, ported or no longer applicable to the new API.
  • QA have put together a test plan for manual testing.

Related Projects