Add-ons/dataDirectory

Addon Data Directory

Addons 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 access a directory specific to it. Then the addon's internal code can refer to the filesystem in a common location.

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.

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?