Firefox/Projects/Extension Manager API: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
No edit summary
 
(21 intermediate revisions by 3 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.


= Status =
* IN FLIGHT
<onlyinclude>
* Implementation in progress in a user repository
Basic management functionality is supported, working on implementing downloads and updates.
* <onlyinclude>Running performance testing, looks like a minor loss but not unexpected. Going to be getting ready for reviews this week</onlyinclude>
</onlyinclude>


= Goals / Use Cases  =
=Goals=


* Primary goals
* Replace extensions.rdf with a sqlite based datastore
** Support a wider range of add-on types managed through the same API
* Implement a new API for accessing all types of add-ons
** Allow application/extension developers to be able to easily query the state of installed items
* Implement a type of XPI extensions that can be [[Extension Manager:Bootstrapped Extensions|installed without restarting]]
** 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
* Create a clean separation between the UI and the backend of the add-ons manager
* Secondary goals
* Lay the groundwork for supporting different types of install manifests in XPI extensions
** Remove direct access to the datastore
* Lay the groundwork that will help us give startup performance improvements
** Simplify the internal code and speed up startup times
* Reduce the number of unecessary EM restarts
** 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  =
=Non-Goals=


The new API is proposed at [[Extension Manager:API Rewrite]]. Some of this work will assist in the implementation of [[Extension Manager:UI Update]].
* Improve startup time
* Make current XPI extensions install without restarts


= Planning  =
=Timeline/Milestones=


== Target Release ==
* 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


Firefox.next. All of the initial work must ship before beta 1.
=Delivery Requirements=


== References ==
* 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


* {{Bug|461973}}
=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 [[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