canmove, Confirmed users
548
edits
No edit summary |
No edit summary |
||
Line 13: | Line 13: | ||
= 2012 Jetpack Roadmap = | = 2012 Jetpack Roadmap = | ||
= The State of Jetpack = | |||
The Jetpack project had a very successful year in 2011. We have | |||
created a set of APIs and tools which present an excellent platform in | |||
which to create Firefox add-ons. We have answered a good number of | |||
use-cases for the audience we initially set out to address and we have | |||
joined Firefox in the train-release cycle to good effect. At this | |||
stage of the life of the project, it is time to step-back and assess | |||
where we are and who we are developing for. | |||
= Changing Focus = | = Changing Focus = | ||
The Jetpack project had a desire from the beginning to make the creation of | The Jetpack project had a desire from the beginning to make the | ||
creation of Firefox add-ons easier than using the existing, | |||
traditional toolset. To that end, we also had the goal of trying to | |||
bring in new developers by utilizing the tools of web development | |||
(javascript, css). | |||
== Who Develops Add-ons? == | |||
As the Jetpack project is into its second year of existence, defining | |||
exactly who develops add-ons for Firefox has become more apparent as | |||
we see who chooses the Add-on SDK and who chooses the traditional | |||
toolset. In our observations there tend to be four types of add-on | |||
developer: the Greasemonkey Scripter, the Shallow-integrator, the | |||
Cross-Browser developer, and the Deep-integrator. | |||
=== Shallow Integrators === | |||
We started the jouney of developing the Add-on SDK with the | |||
Greasemonkey Scripter and Shallow-Integrator in mind. The Add-on SDK | |||
has allowed for minimal changes to the browser, but a powerful set of | |||
APIs to create certain categories of add-ons. We have mostly been | |||
successful at fulfilling the needs of these developers who we can call | |||
"Shallow-integrators" as their add-ons don't have a need to integrate | |||
as tightly with Firefox as many traditional add-ons. | |||
However, with the approach of open web apps, we expect that the | |||
shallow-integrators will be slowly moving away from add-on development | |||
as apps will answer many of their development needs and provide an | |||
even wider distribution. If this is to be true, we need to expand | |||
the SDK to include a different, and now wider, audience. | |||
=== Greasemonkey Scripters === | |||
Another audience we tried to include in the Jetpack project up till | |||
now has been the "Greasemonkey scripter". These are people who simply | |||
want to make modifications to web pages and easily distribute those | |||
changes with anyone. While we have an answer for this audience, we | |||
feel like it is far too heavy and difficult to properly answer the | |||
needs of these people. While we won't be altering the work we have | |||
done here, there are better ways to fulfill this audience which are | |||
likely to be outside of the scope of the Jetpack team's 2012 work[fn:1]. | |||
=== Cross-Browser Developers === | |||
A good number of developers that span all of the other three | |||
categories are Cross-browser developers who need to develop for any | |||
and all browsers. We have not had much focus on these developers and | |||
we are unlikely to anytime soon. The challenge is a tough one and is | |||
answered in small part by us making sure it is easy to develop for | |||
Firefox. Certainly its not a full answer, but for time and resources, | |||
is the best we can do for now. | |||
=== Deep Integrators - A Proposal === | |||
With shallow-integrators having better options coming in the form of | |||
apps, and the Jetpack project never really satisfying the | |||
Greasemonkey-scripters properly, we are proposing that we now turn our | |||
focus to the "Deep-Integrators". | |||
Deep-integrators are the backbone of Firefox's add-on community. They | |||
are the developers who have made Firefox unique among browsers. While | |||
the SDK is still useful to them in its current state, we can make it | |||
an excellent toolset for them that offers a better platform than the | |||
traditional tools have. This shift does not abandon the goal of making | |||
add-on development easier, but it does expand the scope of the toolset | |||
to include APIs and tools which will appeal more to these | |||
deep-integrators. | |||
This roadmap reflects this change in audience and the work we are | |||
proposing to do in 2012 should align better with the deep-integrators. | |||
= The Roadmap = | = The Roadmap = | ||
DRAFT - at this stage the items in this roadmap are simple notes and | |||
will be more full-featured explanations as I get to them! | |||
= Top Priorities = | = Top Priorities = | ||
The top priorities for the Add-on SDK in 2012 are: | The top priorities for the Add-on SDK in 2012 are: Continuation of | ||
Mobile work, new APIs, continuation of l10n work, and moving the add-ons | |||
from the add-on bar to the top of Firefox. | |||
* Mobile | * Mobile | ||
** | |||
We must continue our work on making the development of add-ons for | |||
Firefox mobile easy and familiar using the same APIs and tools used to | |||
create desktop add-ons. We still have a good deal of scope to figure | |||
out with mobile add-ons as there have been so few created to this | |||
point, and a small amount of usage. To that end, we are unsure which | |||
use-cases are the most desired for mobile add-ons. | |||
Because of this lack of scope, we have decided to pick a couple of | |||
APIs which seem important to tackle early, get them running and see | |||
how people use them and what they ask for in addition to these. As we | |||
already have page-mods working, the two additional APIs we have | |||
decided to look at are: | |||
** Preferences API | |||
This allows developers to add simple preferences to their add-on. We | |||
have just landed this for Desktop and need to make sure it works in | |||
Mobile. The initial scope suggests looking at the native android | |||
preferences screen as the UI, though that may change as we investigate. | |||
** Add-on Tab API | ** Add-on Tab API | ||
This is represented in the | |||
[https://wiki.mozilla.org/Features/Jetpack/Add-onTab-API feature page] | |||
for adding the add-on tab to Desktop Firefox, we simply need to port | |||
this over to mobile. | |||
* P1 APIs | |||
** Chrome-mods | |||
An important piece of the SDK to-date has been the ability to simply | |||
alter web pages with the Page-mod API. We wish to allow the same | |||
functionality to developers to alter chrome with a simple script and | |||
CSS. The scope of this work also calls for the ability to revert those | |||
changes (and possibly to add that same reverting function to | |||
page-mods). | |||
** Simpler Ctype API | ** Simpler Ctype API | ||
The initial scope of this is to add a untility that will help add-on | |||
developers who are working with binaries to be able to automatically | |||
scope thier binary and include the proper headers, instantly, to their | |||
add-on. There may be greater scope once this is complete. In addition, | |||
we need to document how binaries can be used with the SDK. | |||
** Places API | ** Places API | ||
The Places API will allow developers access to the bookmarks menu, | |||
bookmarks tool, and possibly more. This needs more scope. | |||
* | ** [https://wiki.mozilla.org/AddonSDKCryptoAPI Crypto API] | ||
The crypto API will give SDK developers simple key/pair functionality | |||
to sign and verify data. | |||
** [https://wiki.mozilla.org/Features/Jetpack/Add-on_SDK_Localization_API_and_Service Continue Localization Work] | |||
We still have a great deal to do to provide the best localization | |||
answer to add-on developers and those who localize add-ons. The scope | |||
of what's left includes answering the html localizing question, | |||
starting the shared-string-translation service, connecting to that | |||
service, and making sure it all integrates with AMO. | |||
** Move Add-ons to top of browser | |||
For a while we have talked about moving the widgets and panels the SDK | |||
provides to the top of the browser and away from the small add-on bar | |||
at the bar. The UX team agrees with this move and has given us some | |||
guidance to go ahead and make this move. | |||
= Secondary Priorities = | = Secondary Priorities = | ||
* Improve XPCOM Access | * Improve XPCOM Access | ||
We currently allow developers access to XPCOM when developing add-ons | |||
with the SDK, but this could be vastly improved. The scope of that | |||
improvement is still being worked on. | |||
* Hidden window | * Hidden window | ||
* SDK as an Add-on | We currently provide a good deal of functionality by hiding a window | ||
and doing things like parsing a DOM in that window. This is rather | |||
hacky and there have often been calls for Firefox to provide a window | |||
to do such things that is not tied to the OS. We want to do this | |||
platform work and provide that window. The scope of use-cases is still | |||
being worked on though some of this is provided in | |||
[https://etherpad.mozilla.org/background-window this etherpad]. | |||
** SDK as an Add-on | |||
Landing SDK in AMO only | |||
There is a great deal of work that is scheduled to happen to make the | |||
SDK an add-on, including the removal of our python code at some | |||
stage. However, the first focus should be the investigation of simply | |||
using AMO as a distribution of the SDK while leaving the SDK exactly | |||
as it is now. If this is possible we could get the benefits of | |||
distribution from AMO earlier than if we waited till the full scope is | |||
reached. | |||
* Land APIs & Loader in Firefox | * Land APIs & Loader in Firefox | ||
== P2 APIs == | |||
* Intercept Network requests | |||
* Add-on Menu | |||
= Tertiary Priorities = | = Tertiary Priorities = | ||
* Extend Functionality in existing APIs | * Extend Functionality in existing APIs | ||
* Subclassing | * Subclassing | ||
* Test add-ons without restarting Firefox | * Test add-ons without restarting Firefox | ||
== P3 APIs == | |||
* Awesome Bar API | |||
* Integration with JS Debugging | |||
= Non-Goals = | |||
* Apps | |||
Mozilla, other browser vendors, and other industry participants | |||
havebeen defining standards, UX affordances, and distribution channels | |||
for the next generation of web apps. But apps differ from add-ons, | |||
even if they sometimes bundle themselves as such for lack of better | |||
distribution channels. | |||
Mozilla Labs' Open Web Applications project is kicking ass here and is | |||
much better positioned to identify and address the exposure and | |||
distribution needs of apps, while Mozilla's developer tools team | |||
headed by Kevin Dangoor is the right locus for activity around tools | |||
for web developers. | |||
Although we can see future work where we can make some of our APIs | |||
available for App developers who wish to have some integration with | |||
Firefox when rnu there, the Jetpack project will not focus on building | |||
tools for app development and distribution in 2012. | |||
Note that the absence of a goal from the priorities list, or its | |||
presence on the anti-list, does not mean we won't accept code that | |||
achieves it. To the contrary, provided such contributions don't work | |||
at cross-purposes to the core goals of the project, we couldn't be | |||
more thrilled to see our technologies get used by the Mozilla and | |||
broader open source communities. | |||
So if you're a Thunderbird developer, a web dev tools hacker, a | |||
XULRunner appmeister, or anyone else who wants to see Add-on SDK and | |||
Builder (or their component parts) better support your own particular | |||
use cases (or get repurposed into your own new products), know that we | |||
want to see that too! So please don't hesitate to dream about how the | |||
project can help you, talk about your ideas with us, and make them | |||
happen. Besides code to see some of these things happen, we also | |||
desire a commitment to supporting that code through our train release | |||
process which we cannot afford at this time. | |||
= Persistant Goals = | |||
There are goals we shall strive to achieve in the Jetpack project that | |||
may or may not be explicitly written in this Roadmap or in our | |||
Quarterly goals. However, these things will always be goals for the | |||
project and any products which we create: | |||
* Performance | |||
We must always measure our preformance and be thoughtful of how the | |||
Add-on SDK affects the performance of Firefox. | |||
* Footprint | |||
We should try to make sure that everything we create is as small as it | |||
can be while still providing the functionality we think is necessary. | |||
* Security | |||
We must ensure the security of all our users and make sure that we are | |||
consistently reviewing, with the help of security experts, our code to | |||
be as secure as we can make it. | |||
* Simplicity | |||
We should strive to provide the simplest structure to our APIs and | |||
tools to make sure the Jetpack experience is easy to use. In addition | |||
we should keep the codebase clean and simple to ease and encourage | |||
contributions. | |||
* Memory Consumption | |||
We should strive to keep memory consumption of an add-on built with | |||
our high-level APIs as small as possible. | |||
* Stability | |||
We will strive to make the Add-on SDK as stable as possible and | |||
respond to issues as quickly as possible to make sure that users can | |||
trust the SDK for their development. | |||
= Footnotes = | |||
[fn:1] We can make Greasemonkey scripting far easier than either | |||
Jetpack or Greasemonkey has done by creating a tool that rides on | |||
top of our devtools and allows a page-modification to happen with | |||
the click of a button. The proposal for such a tool can be found in | |||
its own feature page that is not specifically assigned to the | |||
Jetpack project. | |||
= Goals = | = Goals = | ||
[https://wiki.mozilla.org/Jetpack/Goals/2012-Goals 2012 Goals By Quarter] | [https://wiki.mozilla.org/Jetpack/Goals/2012-Goals 2012 Goals By Quarter] |