571285 - Restructure package/module structure and/or reference documentation to make more sense to Addon developers

Status: RESOLVED DUPLICATE of bug 592848

(Add-on SDK Graveyard :: General, defect)

Description

[Atul Varma [:atul]]

It's currently very difficult to understand what modules are relevant and which are irrelevant for Addon developers:

  https://jetpack.mozillalabs.com/sdk/0.4/docs/

For instance, 'xhr' and 'page-worker' are useful to addon developers, but 'observer-service' is only of use to Jetpack Platform developers, yet they're all jumbled into the same place in the docs.

One solution is to separate different modules into new packages, e.g. 'jetpack-core-chrome' and 'jetpack-core', but there are actually some modules that fit into both categories. IA-wise, it seems like tagging might make more sense here.

Comment 1

[Atul Varma [:atul]]

While I haven't yet come up with a solid proposal, and all the things I've thought of so far would involve a lot of work and restructuring, I have a stop-gap measure that will at least make it easier for developers to make sense of our documentation for the imminent FlightDeck and Jetpack SDK releases.

This is simply to add a header to the .md documentation for all "low-level" modules--that is, modules which are irrelevant to addon developers--that mentions the module is low-level and not intended for use by addon developers.

Comment 2

[Atul Varma [:atul]]

It looks like only the jetpack-core package contains any modules that addon developers would really care about--the development-mode, nsjetpack, and test-harness packages are all supporting infrastructure for the Jetpack platform and toolchain.

Within jetpack-core, these modules would be of interest to addon developers:

* xhr
* collection
* context-menu
* page-worker
* private-browsing
* self
* simple-storage
* timer
* unit-test
* widget

And these either wouldn't be of interest, or carry so much authority with their use that we'd much rather developers use alternatives (e.g. simple-storage instead of file):

* api-utils
* byte-streams
* cuddlefish
* errors
* file
* memory
* observer-service
* plain-text-console
* preferences-service
* securable-module
* tab-browser
* text-streams
* traceback
* unload
* url
* window-utils
* xpcom
* xul-app

Comment 3

[Atul Varma [:atul]]

Another option I discussed with Myk is labeling the second list above as "private implementation" files, signified by moving them into a directory called "private", so that importing e.g. tab-browser would be doing via require("private/tab-browser").  The advantage of this is that not only will add-on developers know not to look there, but we'll also have a bit more social freedom to change the interfaces of the private modules if necessary--that is, changing an API for a private module won't be terribly unexpected, while changing the API of a public one would be.

Comment 4

[Myk Melez [:myk] [@mykmelez]]

I like the option described in comment 3.

I also think we should rename "jetpack-core" to "core" in the process of making this change.

Comment 5

[Myk Melez [:myk] [@mykmelez]]

Erm, the 0.8 deliverable is actually bug 592848 (although it's possible that this bug will get fixed in the process of fixing that one, if we decide to merge the concepts of "private" and "low-level" in the process of fixing that bug).

Comment 6

[Atul Varma [:atul]]

The current plan for this is to fix bug 596089, "Distinguish between high and low-level packages", and then move all the low-level modules in jetpack-core out into a low-level package.

Comment 7

[Atul Varma [:atul]]

I'm going to go ahead and file this as a duplicate of bug 592848.

Comment 8

[Myk Melez [:myk] [@mykmelez]]

The Add-on SDK is no longer a Mozilla Labs experiment and has become a big enough project to warrant its own Bugzilla product, so the "Add-on SDK" product has been created for it, and I am moving its bugs to that product.

To filter bugmail related to this change, filter on the word "looptid".