Add-on SDK Roadmap Update!

44 views
Skip to first unread message

David Mason

unread,
Aug 12, 2011, 1:33:22 PM8/12/11
to dev-pl...@lists.mozilla.org

Its been quite a few months since we shared the greater vision for the Jetpack project and the Add-on SDK as a product. A lot has happened since then, including the release of Add-on SDK 1.0 and the growth of a team of talented people to keep the momentum going. Still, its always good to take some time, think about where we are going, and decide which parts are most important. So let's do it!

You know, this is a roadmap... In my mind that means its *always* in draft form. We will always need to take a look at what things are important and how they should fit in to the ongoing work. So let's make a deal and consider this thing dynamic and living - then we don't have to worry about labeling it a draft.

The list of goals here are many and not easy and while we've grown the internal Mozilla Jetpack team, we still want and need contributions from you Rocketeers out there who are using the SDK on a regular basis and identify missing pieces or are just interested in helping out with some or all of these goals.

Keep in mind that we've always had the plan to keep the core of the Add-on SDK small and relatively conservative when it comes to features. What we would rather have is a large set of contributed, and shared, libraries to extend the functionality for add-on developers. This opens up a far more extensive set of tools and a better community for anyone who wishes to create an add-on, and frankly, just feels like the Mozilla way!

*Let's reset for a minute*

The Jetpack project has always had the goal to make extensions easy to develop, and easy to install. While it started out as an experiment in 2009, we soon did a rewrite and moved on to product development while graduating the project from the Mozilla Labs in 2010. With the release of Add-on SDK 1.0 we have made a set of APIs that allow for the majority of add-on use-cases to be developed easily and with open web tools (html, css, & javascript). In addition, as they are restartless by default, add-ons developed with the Add-on SDK are definitely easy to install. To be sure, the Add-on SDK is no longer a prototype or experiment but the tasks ahead of us, while filling in holes in some cases, will be every bit as challenging as the initial creation of this project. We can't say that the Add-on SDK is the answer for all of your add-on development needs yet, but we want to get there. For that, we want your help!

*The Priorities*

So lets get to it. Many people may have noticed lately that the Mozilla project has done a bit of shifting to make sure we are answering the changing landscape of browsing and computing. To that end, we have to focus more on emerging mobile devices and how people want to use these devices. We Rocketeers have to make sure we are also making that shift. This means that our support of mobile has to be at the top of our list. Keep in mind that just because a feature didn't make it to the top of the list, doesn't mean it won't get done before some of the top items. Its hard for people to focus solely on one thing for a long time, and some of the other items (or pieces of the other items) are easier to develop and test than the top priorities. Nonetheless, I expect that you will see a great deal of movement on these higher priority items even though they are the more complicated tasks.

The Mozilla Products team has also been hard at work on new set of processes and tools to help explain new features and why we want them. The new "Feature Pages" are being used by the Jetpack team so for any of the priorities listed below you can click on the link to the Feature Page for it and see more detail and what the latest plans are with them.

By the way, any time you want to check on the latest changes to the Roadmap, you can always look here: https://wiki.mozilla.org/Jetpack/Roadmap


*Top Priorities*

Our top priorities for the second half of 2011 into 2012 are:

1) Support Firefox Mobile. As we now all understand, the web experience is moving towards smaller devices, we have to make sure that any developer creating an add-on via Jetpack will find that their add-on just works in mobile. Mozilla cares as much about user choice and personalization on mobile devices as it does on the desktop, Jetpack must reflect that with no work from end-user developers.

https://wiki.mozilla.org/Features/Jetpack/SDK_Support_for_Firefox_for_Mobile_Addons

2) Enable jetpack to always create add-ons that take advantage of Electrolysis (e10s) to run in a separate process. Running an add-on in a separate process is important for users and the add-on developer as it makes it much easier to determine if an add-on is affecting the browser's performance. In addition, there may be some security enhancement as its much harder to exploit a vulnerability if its being run in a separate process. For Jetpack, we want to ensure that our users never even have to think about e10s or how to use it for their add-ons to run in a separate process.

https://wiki.mozilla.org/Features/Jetpack/Out-of-Process_Addons

In addition, we also need to ensure that for the elements the Add-on SDK exposes that need to run in particular processes that are *not* the add-on process, they are doing so (again, without any worry from the add-on developer). We recognized that these two bits are related pieces of work despite the orthogonal approach we plan to take in developing them. Nonetheless, a new feature page is being developed for supporting the other processes we need to support.

https://wiki.mozilla.org/Features/Jetpack/Browser-e10s-Support

3) Add-on Localization API and Service. Its important that Jetpack no longer lingers behind in the the world-wide reach Mozilla has worked hard to obtain. We must have a localization solution that allows our developers to get localized add-ons with minimal effort on their part. Add-on localization in the SDK comprises a simple, high-level API for specifying the strings to localize, a localization service to which add-ons distributed by addons.mozilla.org (AMO) are automatically submitted for localization, a web application through which localizers can localize add-ons, and automatic repackaging of AMO-distributed add-ons with new and updated localizations.

https://wiki.mozilla.org/Features/Jetpack/Add-on_SDK_Localization_API_and_Service


*Secondary Priorities*

1) Create a path for developers using the traditional tools to move to jetpack. If we are successful in bringing in new developers to creating add-ons for Firefox, we must not forget the developers who have been using the traditional toolset. With the inclusion of features such as e10s and mobile, it becomes imperative that we offer the easiest methods possible to create add-ons that work with these new technologies and platforms. We see Jetpack as being a great path for our current add-on developers to start taking advantage of these new features - as long as we can make the porting equally simple. This work may include creating tools which will automatically help developers port their existing add-ons, as well as a good set of documentation and examples to help them understand the differences in approach.

https://wiki.mozilla.org/Features/Jetpack/Traditional_Addon_Conversion_to_SDK_Platform


2) Simplify the Add-on SDK. While Jetpack is a simple development tool to use as compared to the traditional add-ons tools Mozilla has offered, we have to recognize that simplicity opens the door for more participation. With more participation comes a greater democracy of ideas and implementations - all of which can benefit the open web. Simplifying Jetpack even more is a high priority because it is one and the same with Mozilla's mission.

https://wiki.mozilla.org/Features/Jetpack/Simplify_the_Add-on_SDK

3) Add-on SDK: The missing pieces. There are several notable Firefox features we do not yet support. These would be simple APIs to offer support for:

- Prefs API
- Places API
- Sidebar API
- Add-on Tab API
- Tab Groups API

- minimal XPIs
- packed XPIs
- add-on testing without browser restart

https://wiki.mozilla.org/Features/Jetpack/Add-on_SDK:_the_Missing_Pieces


4) Add-on SDK as an Add-on. We currently ship the Add-on SDK as a zip file or source code through github. This may not be the best way for us to distribute the SDK. First, we have a built-in automated update mechanism with addons.mozilla.org which also provides support for stable and beta distribution channels. Second, if we can get the SDK to package itself we have a chance for SDK developers to "eat their own dogfood" - testing the packaging and performance everyday. Finally, possibly building upon the original prototype as well as Alexandre Poirot's work of porting the SDK to an add-on we can start to offload some of the Builder's time-consuming functions to the client while also avoiding difficult dependencies for Add-on SDK users.

https://wiki.mozilla.org/Features/Jetpack/Add-on_SDK_as_an_Addon

5) Add-on SDK Debugging. Debugging has come a long way since the old style of dumping errors to printf. However, Add-on SDK users might notice... we dump to printf! There are many debugging additions we can make to the SDK, especially if we take a cue from our awesome web dev tools team. Some of these items could include:

- introspection
- profiling
- setting breakpoints
- stepping through code

https://wiki.mozilla.org/Features/Jetpack/Add-on_SDK_Debugging

6) Make Add-on SDK Hug the Web Harder. Jetpack has done a great job in embracing open web technologies to create a robust development toolset. However, developing an add-on is still more different from developing a web page than it has to be. We need to make sure we are supporting the most common and useful elements of web development to ensure the platform is as inclusive as it can be.

https://wiki.mozilla.org/Features/Jetpack/Make_Add-on_SDK_Hug_the_Web_Harder


Non-Goals

If you still have a copy of the last roadmap around you might notice that the non-goals are pretty much the same. Keep in mind though, that just because we have these items listed as non-goals for this roadmap doesn't mean they can't become goals at some future date. Its just important to remind ourselves of the constraints of which our current development needs to fit in to. To that end, here are the things we are not trying to accomplish:

1. Deep extensibility. The traditional add-on platform, with features like XUL overlays and XPCOM components, was designed for deep extensibility. Indeed, you can do almost anything to Firefox with the traditional platform. But the vast majority of existing and potential add-ons don't need this capability; the remainder can still be implemented using the traditional add-on platform; and projects are better positioned to explore a potential future replacement. The Jetpack project will leave deep extensibility to the traditional add-on platform and Mozilla Labs experiments. Having said that, its important to remember that deep extensibility is possible with the SDK; it just requires you to dive under the covers of our supported APIs.

2. Apps. Mozilla, other browser vendors, and other industry participants are hard at work 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. The Mozilla Open Web Apps team 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. The Jetpack project will not build tools for app development and distribution.

3. Firefox-SDK integration. The SDK and Builder bundle API implementations with each individual add-on. This strategy has worked for us so far through the 1.0 release and is still a good plan for our needs. Having said that, there is a good deal of ongoing discussion about integrating with firefox we are taking part in with the community. At this point, it is still too early to include any steps on this roadmap related to any of the conclusions coming from these discussions so it will still be listed as a Non-goal.

Recently, as a part of the conversations around integration and the development and distribution of the Add-on SDK, the Jetpack team Tech Lead, Myk Melez, wrote up his thoughts on why the Add-on SDK doesn't land in Mozilla-central: http://mykzilla.blogspot.com/2011/08/why-add-on-sdk-doesnt-land-in-mozilla.html


Development Plan

The Jetpack team decided during the 1.0 release that we would move our development to a train cycle that closely follows the Firefox development cycle. This was done mostly for maintenance reasons, which allow us to keep up with the new versions of Firefox. This will ensure that developers can have their add-ons rebuilt automatically on the Add-on Builder or addons.mozilla.org to work with the new versions of the browser. In addition, we will be working on our top three priorities with an outlook of 3 to 6 months for each item. Our version numbers will only increase by dots until we land major changes or breaking changes. This will be done to make sure that people recognize that there is something important to recognize with the release. More information about our development plan can be found here: https://wiki.mozilla.org/Jetpack/Development_Process


As usual, we would love to hear your feedback on our plan!

Thanks,

Dave

Archaeopteryx

unread,
Aug 12, 2011, 2:34:52 PM8/12/11
to
Re: TL;DR: Bringing Jetpack to Mobile is now the top priority, so
resources for extending/enhancing Jetpack are scarce.

> What we would rather have is a large set of contributed,
> and shared, libraries to extend the functionality for add-on
> developers. This opens up a far more extensive set of tools and a
> better community for anyone who wishes to create an add-on, and
> frankly, just feels like the Mozilla way!

1. Please add more structure to the library listing (and better don't
silently push code written in the builder to the public by default).
2. Will the libraries be reviewed (= reliable for developers)?
3. Adding third-party dependencies into one's code hoping that it won't
break worries me.

> With the release of Add-on SDK 1.0 we have made a set of APIs
> that allow for the majority of add-on use-cases to be developed
> easily and with open web tools (html, css,& javascript).

That's often claimed, but are there statistics to support this statement?

> 3) Add-on Localization API and Service.

I don't know of any service which is able to do this at a level
sufficient for Mozilla's quality standards. Especially without the
context, it's sometimes impossible to get the correct translation as a
word can have more than one meaning (and gender etc.)

> 1) Create a path for developers using the traditional tools to move
> to jetpack.

From
https://wiki.mozilla.org/Features/Jetpack/Traditional_Addon_Conversion_to_SDK_Platform
:
"Develop tools that identify kinds of chrome modification and suggest
SDK APIs that developers can use to make similar kinds of modifications.
Develop tools that identify XPCOM services and automatically convert
them to CommonJS modules."
So you plan to ship the add-on with the CommonJS modules? This means the
developer has to recompile the extension to get these files updated? Is
a proxy mapping XPCOM calls not doable?

> Add-on Tab API
Do you mean an API implementing the functions and information getters
and setters used in the Add-on Tab or something to extend its UI?

Archaeopteryx, AMO Editor

Ehsan Akhgari

unread,
Aug 15, 2011, 1:40:51 PM8/15/11
to David Mason, dev-pl...@lists.mozilla.org
Thanks a lot for posting this detailed roadmap, David!

On 11-08-12 1:33 PM, David Mason wrote:
> 3) Add-on SDK: The missing pieces. There are several notable Firefox features we do not yet support. These would be simple APIs to offer support for:
>
> - Prefs API
> - Places API
> - Sidebar API
> - Add-on Tab API
> - Tab Groups API
>
> - minimal XPIs
> - packed XPIs
> - add-on testing without browser restart
>
> https://wiki.mozilla.org/Features/Jetpack/Add-on_SDK:_the_Missing_Pieces

Are we also looking into getting a localization API for the Add-on SDK?
It would be really great if the Add-on SDK enables developers to write
add-ons which support being localized, without making them come up with
their own solutions for l10n.

Cheers,
Ehsan

Ehsan Akhgari

unread,
Aug 15, 2011, 1:42:48 PM8/15/11
to David Mason, dev-pl...@lists.mozilla.org
On Mon, Aug 15, 2011 at 1:40 PM, Ehsan Akhgari <ehsan....@gmail.com>wrote:

> Thanks a lot for posting this detailed roadmap, David!
>
>
> On 11-08-12 1:33 PM, David Mason wrote:
>
>> 3) Add-on SDK: The missing pieces. There are several notable Firefox
>> features we do not yet support. These would be simple APIs to offer support
>> for:
>>
>> - Prefs API
>> - Places API
>> - Sidebar API
>> - Add-on Tab API
>> - Tab Groups API
>>
>> - minimal XPIs
>> - packed XPIs
>> - add-on testing without browser restart
>>

>> https://wiki.mozilla.org/**Features/Jetpack/Add-on_SDK:_**
>> the_Missing_Pieces<https://wiki.mozilla.org/Features/Jetpack/Add-on_SDK:_the_Missing_Pieces>


>>
>
> Are we also looking into getting a localization API for the Add-on SDK? It
> would be really great if the Add-on SDK enables developers to write add-ons
> which support being localized, without making them come up with their own
> solutions for l10n.
>

Which is a question that you had answered in another part of the roadmap!
Sorry for the noise. :-)


Ehsan

Myk Melez

unread,
Aug 19, 2011, 7:04:54 PM8/19/11
to Archaeopteryx, dev-pl...@lists.mozilla.org
On 2011-08-12 11:34 AM, Archaeopteryx wrote:

> Dave Mason wrote:
>> What we would rather have is a large set of contributed,
>> and shared, libraries to extend the functionality for add-on
>> developers. This opens up a far more extensive set of tools and a
>> better community for anyone who wishes to create an add-on, and
>> frankly, just feels like the Mozilla way!
> 1. Please add more structure to the library listing (and better don't
> silently push code written in the builder to the public by default).
> 2. Will the libraries be reviewed (= reliable for developers)?
> 3. Adding third-party dependencies into one's code hoping that it
> won't break worries me.
Daniel Buchner may be best positioned to address these concerns,
although I'm not sure if he's subscribed to this list. Perhaps post
these in the Jetpack discussion group
<http://groups.google.com/group/mozilla-labs-jetpack>?

>> With the release of Add-on SDK 1.0 we have made a set of APIs
>> that allow for the majority of add-on use-cases to be developed
>> easily and with open web tools (html, css,& javascript).
> That's often claimed, but are there statistics to support this statement?
>

I don't have stats, not sure if Dave does, but my intuition suggests
that the SDK's high-level APIs cover about 60% of use cases and a
greater percentage of addons (including the number of Greasemonkey
scripts that can now be written using the SDK's Page Mod API).

Nevertheless, we should analyze traditional addons and continue building
out the core API set as needed to get to 80%, 95%, or whatever percent
we want to target.

>> 3) Add-on Localization API and Service.
> I don't know of any service which is able to do this at a level
> sufficient for Mozilla's quality standards. Especially without the
> context, it's sometimes impossible to get the correct translation as a
> word can have more than one meaning (and gender etc.)

I think we'll need to build this service in addition to implementing the
API as part of standing up the feature. Your note about context makes a
lot of sense, and it suggests that there should be a mechanism for the
API to provide context for the strings for which it requests localization.

>> 1) Create a path for developers using the traditional tools to move
>> to jetpack.
> From
> https://wiki.mozilla.org/Features/Jetpack/Traditional_Addon_Conversion_to_SDK_Platform
> :
> "Develop tools that identify kinds of chrome modification and suggest
> SDK APIs that developers can use to make similar kinds of
> modifications. Develop tools that identify XPCOM services and
> automatically convert them to CommonJS modules."
> So you plan to ship the add-on with the CommonJS modules? This means
> the developer has to recompile the extension to get these files
> updated? Is a proxy mapping XPCOM calls not doable?

That feature page is an early draft, and we haven't worked out exactly
what we're going to do yet. At the moment, the SDK has an experimental
feature that exposes XPCOM APIs directly, and there are a variety of
options for migrating addons that use XPCOM APIs to the new platform. So
I wouldn't read too much into this, but I would be interested in your
thoughts on what would be useful to provide!

>> Add-on Tab API
> Do you mean an API implementing the functions and information getters
> and setters used in the Add-on Tab or something to extend its UI?

Actually, this isn't about the Add-ons Manager tab, it's about an API
for opening tabs that behave similarly to the Add-on Manager tab in that
they don't have a navigation bar and contain addon chrome rather than
web content. Perhaps "Chrome Tab API" would be a clearer name for it.

-myk

Reply all
Reply to author
Forward
0 new messages