Addon Data Directory

Add-ons may want to store settings or other data on the local computer. In the past, add-ons would use preferences or an arbitrary location on the user's filesystem. Preferences are less than ideal, so each Addon object should provide built-in helpers to read and write data specific to the add-on.

Bugzilla bug 915838 is for the implementation of whatever design we decide on here.

Option 1: Direct access to a nsIFile object

  get dataDirectory() {
    try {
      return FileUtils.getFile(KEY_PROFILEDIR, ["extension-data", this.id], false);
    }
    catch(e) {
      return null;
    }
  },

We may just want to expose an Addon.dataDirectory property. This property points to a folder which is not initially guaranteed to exist. (Unless an add-on demands it, we don't need to create it.) Add-on developers can then either migrate existing files to this directory. They can also create SQLite databases, JSON files, and other settings there.

Option 2: Indirect access through friendly API's

We may create the data directory for an add-on, but expose a special Addon.localData API with various methods (.json, .getDBConnection(dbName), etc) for addon developers.

(Please flesh this section out with ideas and proposals!)

Other considerations

• We intend this as a data directory for the add-on to use; should AMO policy set some arbitrary limit on how much filesystem space an add-on may use here? (There's nothing preventing an add-on from storing information elsewhere on the filesystem.)
• Do we similarly want to limit the file types that can live in the data directory? If kept to a simple settings folder, JSON (YAML for comments), XML and SQLite might be all we desire there.
• Do we want to remove an addon's data directory when the addon has been uninstalled? (Consensus in #addons is no.) Do we want to schedule a clean-up after, say, six months?
• When doing a "profile reset", clearing all add-ons from a profile, would we want to remove the data directories then?
• We'll need to sanitize the add-on id a little bit here; if an add-on id contains a slash, that's not a good thing.
• Do we want to enforce the existence of the extension-data directory itself, so that add-on providers don't have to create that folder too?

Comments

Sample

Please make your comments with your IRC nick attached. Example:

• (firebot) I believe we should...

Actual comments

• (Yoric) Please don't use nsIFile, ever. We are attempting to get rid of nsIFile in JS code. If you need file access in JS, you should use OS.File.

• (Yoric) Please design your data directory so that it can be accessed from chrome worker threads.

• (Yoric) When time comes to make writes shutdown-safe, please come and talk to me.

• (techlivezheng) As long as the add-on places its data in the data directory, no limitation should be set on size or the file type.

• (techlivezheng) The removal of the data directory should be left to the add-on author to decide. Some add-ons, e.g. session manager or scrapbook, their data is very important. No automatic clean-up should be scheduled, though it is nice to have a UI interface to show the left over data directories for user to manage. On profile reset, the data directories should be cleared, or at least, move and backup them in another place.

• (techlivezheng) "We'll need to sanitize the add-on id a little bit here; if an add-on id contains a slash, that's not a good thing." Absolutely.

• (techlivezheng) "Do we want to enforce the existence of the extension-data directory itself, so that add-on providers don't have to create that folder too?" This should be smart, if a write action is taken through the API, then the directory should be created automatically.