Jetpack/Roadmap-2011: Difference between revisions

Jump to navigation Jump to search
fix links (convert from HTML to wiki-style)
(initial version of updated roadmap with visibility through end of 2011)
(fix links (convert from HTML to wiki-style))
Line 16: Line 16:
Three tasks to which we will not set ourselves in 2011:
Three tasks to which we will not set ourselves in 2011:


# <p>Deep extensibility.</p><p>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.</p><p>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 like <a href="http://mozillalabs.com/chromeless">Mozilla Labs' Chromeless Browser experiment</a> are better positioned to explore a potential future replacement.</p><p>The Jetpack project will leave deep extensibility to the traditional add-on platform and Mozilla Labs experiments.</p>
# <p>Deep extensibility.</p><p>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.</p><p>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 like [http://mozillalabs.com/chromeless Mozilla Labs' Chromeless Browser experiment] are better positioned to explore a potential future replacement.</p><p>The Jetpack project will leave deep extensibility to the traditional add-on platform and Mozilla Labs experiments.</p>
# <p>Apps.</p><p>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.</p><p><a href="https://apps.mozillalabs.com/">Mozilla Labs' Open Web Applications project</a> 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.</p><p>The Jetpack project will not build tools for app development and distribution.</p>
# <p>Apps.</p><p>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.</p><p>[https://apps.mozillalabs.com/ 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.</p><p>The Jetpack project will not build tools for app development and distribution.</p>
# <p>Firefox-SDK integration.</p><p>The SDK and Builder bundle API implementations with each individual add-on. This strategy, akin to static linking for compiled code, has its downsides, but it allows the products and add-on platform to evolve independently of the Firefox release cycle, avoids <a href="http://en.wikipedia.org/wiki/Dependency_hell">dependency hell</a>, and makes it easier to architect and nurture a rich ecosystem of third-party APIs.</p><p>The Jetpack project will not land its API implementations in the Firefox tree and ship them with Firefox.</p>
# <p>Firefox-SDK integration.</p><p>The SDK and Builder bundle API implementations with each individual add-on. This strategy, akin to static linking for compiled code, has its downsides, but it allows the products and add-on platform to evolve independently of the Firefox release cycle, avoids [http://en.wikipedia.org/wiki/Dependency_hell dependency hell], and makes it easier to architect and nurture a rich ecosystem of third-party APIs.</p><p>The Jetpack project will not land its API implementations in the Firefox tree and ship them with Firefox.</p>


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.
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.
canmove, Confirmed users
2,056

edits

Navigation menu