Confirmed users
360
edits
(add disk seek performance optimization as a proposed development priority) |
(Update the page per discussion with storage advisory group) |
||
| Line 1: | Line 1: | ||
Storage | Storage can mean many things in Gecko and Firefox. | ||
Possibilities include: | |||
* mozStorage, the API that lives under [https://searchfox.org/mozilla-central/source/storage storage/] in the source tree. This is a C++ wrapper around SQLite that is also exposed to JS via both XPCOM/XPConnect ([https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Storage API docs]) and via a friendlier JS wrapper, [https://developer.mozilla.org/en-US/docs/Mozilla/JavaScript_code_modules/Sqlite.jsm SQLite.jsm]. Bug 1482608 also | |||
* The profile "storage/" directory that holds per-origin storage managed by the QuotaManager subsystem and its clients: IndexedDB, the Cache API, and the asm.js cache (which will be removed). | |||
=== | == Storage Alternatives == | ||
There are many options for storing data in Gecko. The Browser Architecture Group has [https://github.com/mozilla/firefox-data-store-docs cataloged] many of the existing uses. | |||
If you are looking for a way to store data in Firefox, here are the usual options: | |||
* JSON flat files. This usually is not a viable option from C++ because we don't have convenient ways to manipulate JS objects from C++. | |||
* [https://github.com/mozilla/rkv rkv], a "simple, humane, typed Rust interface to LMDB". LMDB is a memory-mapped flat file database. | |||
* SQLite via the mozStorage API or bindings. You should *NOT* directly access the SQLite API. If you are using rust code and would like a better binding API than mozStorage, that makes sense, but please reach out to the Storage Advisory Group so that we can reach consensus. We do not want to have N separate bindings to SQLite, especially since mozStorage is responsible for global configuration settings that could fight with other SQLite bindings. | |||