Confirmed users
2
edits
Add-ons/dataDirectory: Difference between revisions
→Actual comments
| (10 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
= Addon Data Directory = | = 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. [https://bugzilla.mozilla.org/show_bug.cgi?id=872980 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 [https://bugzilla.mozilla.org/show_bug.cgi?id=915838 bug 915838] is for the implementation of whatever design we decide on here. | |||
== Option 1: Direct access to a nsIFile object == | == Option 1: Direct access to a nsIFile object == | ||
| Line 21: | Line 23: | ||
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. | ||
(Please flesh this section out with ideas and proposals!) | |||
== Other considerations == | == Other considerations == | ||
| Line 29: | Line 33: | ||
* 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. | ||
* 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 == | == Comments == | ||
=== Sample === | |||
Please make your comments with your IRC nick attached. Example: | Please make your comments with your IRC nick attached. Example: | ||
* (firebot) I believe we should... | * (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. | |||