Confirmed users
146
edits
Add-ons/dataDirectory: Difference between revisions
no edit summary
No edit summary |
|||
| Line 21: | Line 21: | ||
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. | 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? | |||