Add-ons/dataDirectory

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.