Add-ons/dataDirectory: Difference between revisions
Line 29: | Line 29: | ||
* When doing a "profile reset", clearing all add-ons from a profile, would we want to remove the data directories then? | * 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. | * 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. | ||
== Comments == | |||
Please make your comments with your IRC nick attached. Example: | |||
* (firebot) I believe we should... |
Revision as of 19:52, 12 September 2013
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?
- 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.
Comments
Please make your comments with your IRC nick attached. Example:
- (firebot) I believe we should...