JSONFile.jsm, a new module to help with serializing JSON to disk

[Ethan Glasser-Camp]

On the subject of storage systems that are available in Gecko, I'd be
remiss if I didn't mention kinto.js, which is part of the Kinto suite, a
set of tools meant to build offline-first web applications. (I work on the
team that built Kinto.) If you want a key-value ("document") store with
deliberately simplistic synchronization primitives, kinto might interest
you. kinto.js is available in Gecko with a backend based on Sqlite. (You
can also use kinto.js in non-Gecko projects, where it uses IndexedDB.)

I'm using kinto.js to implement chrome.storage.sync, but it's also been
used to handle certificate blocklist updates. See
services/common/blocklist-clients.js for an example of usage.

Ethan


On Tue, Oct 11, 2016 at 4:33 PM, Richard Newman <rnewman at mozilla.com> wrote:

> As some of you know, Nick Alexander and I have been working on an
> exploratory storage system called Datomish
> <https://github.com/mozilla/datomish/>[1]. There's a blog post queued up,
> but part of the idea is to make fairly fast, durable, flexible,
> multi-consumer storage way easier to handle than starting out with
> Sqlite.jsm and trying to figure out who owns the schema migration code.
>
> One way to think about it: what if Prefs — the de facto lightweight
> multi-consumer store in Gecko — was graph-structured, supported upserts and
> indices and rules and transactions and full-text querying, and was actually
> durable?
>
> That's not at all in competition with a simple JSON file store — which
> remains an excellent way to meet special-purpose, small-size storage needs,
> and I'm glad to see Luke and co step up to maintain one!  — but it does
> address many of the concerns in that original "Storage in Gecko" thread, so
> I figured this was as good a place as any to mention it.
>
> -R
>
> [1] <https://github.com/mozilla/datomish/>
>
> On Tue, Oct 11, 2016 at 12:53 PM, Chris Peterson <cpeterson at mozilla.com>
> wrote:
>
>> Is JSONFile.jsm suitable for the long-sought Gecko storage system that's
>> not as hacky as about:config prefs or as heavyweight as SQLite? btw, I
>> didn't see any tests specifically for JSONFile.jsm. Are the other Password
>> Manager tests on top of JSONFile.jsm adequate test coverage?
>>
>> Here is a link to a 2013 "Storage in Gecko" thread on dev-platform
>> bikeshedding requirements around sync/async APIs and atomic and lazy I/O.
>> This thread spun out bug 866238 ("implement simple key-value store on top
>> of IndexedDB").
>>
>> https://groups.google.com/d/msg/mozilla.dev.platform/vYbQqkq
>> Gzlo/YYIvd-rB9ToJ
>>
>>
>>
>> On 10/11/2016 7:53 AM, Luke Chang wrote:
>>
>> Hey folks,
>>
>> This is a notice about a module, JSONFile.jsm, just landed in
>> "toolkit/modules".
>>
>> Matt, Steve and I have been working on Form Autofill [1]. While
>> implementing, we intend to leverage modules of Password Manager because of
>> their similar behaviors. LoginStore.jsm [2] is one of those modules.
>>
>> The above-mentioned JSONFile.jsm is basically separated from
>> LoginStore.jsm, which is in charge of storing login-related data in a
>> ".json" file. In order to increase the reusability of such JSON-formatted
>> storage that we're going to use in Form Autofill as well, we refactored
>> LoginStore.jsm. More specifically, those IO-specific APIs were generalized
>> and moved to JSONFile.jsm. Therefore, LoginStore.jsm will focus on
>> schema-related operations such as data migrations.
>>
>> To sum up, you can now utilize JSONFile.jsm to store simple data in a
>> single file as long as the data can be serialized to JSON format. More
>> details can be found in bug 1304322 [3].
>>
>> Thanks,
>> Luke
>>
>> [1] https://wiki.mozilla.org/Firefox/Features/Form_Autofill
>> [2] https://dxr.mozilla.org/mozilla-central/source/toolkit/
>> components/passwordmgr/LoginStore.jsm
>> [3] https://bugzilla.mozilla.org/show_bug.cgi?id=1304322
>>
>>
>>
>> _______________________________________________
>> firefox-dev mailing listfirefox-dev at mozilla.orghttps://mail.mozilla.org/listinfo/firefox-dev
>>
>>
>>
>> _______________________________________________
>> firefox-dev mailing list
>> firefox-dev at mozilla.org
>> https://mail.mozilla.org/listinfo/firefox-dev
>>
>>
>
> _______________________________________________
> firefox-dev mailing list
> firefox-dev at mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/firefox-dev/attachments/20161014/b0d2984a/attachment.html>