Vocabulary and API for preferences storage

[rnewman]

Open questions:

• I assume that we want prefs to live in memory for speed. Should these be in memory in the frontend (which requires a pref change notification from UAS to each frontend, and allows different windows to get out of sync), in memory in the UAS (which just makes lookups faster), or both?
• If in memory anywhere: is this a write-through cache (modifies both disk and in-memory: safest, slow writes), write-around cache (writes to disk and invalidates the cache), or write-back (writes to cache, later flushes to disk: fastest, chance of losing data as in Gecko)?
• What do we want to be able to model? String key-value pairs? Typed values? Do we want type constraints on preferences? Do we need loose keys ("foo.bar.asdlkasjoi21" = 92), or can we model prefs as a schema fragment in Datomish?
• Do different windows get their own prefs? Do different apps/channels/etc. get their own prefs? In other words, is prefs a global namespace or scoped?

@jsantell, what are you thinking?

[jsantell]

Initial thought is we should make sure that any choice here will work atleast as good or better for Firefox, as that seems like it'd still be the biggest impact for the UAS.

• Global vs Scoped preferences and branching: Global seems like the safer option, as we can always model in scoped prefs via that, like branching: window.dimensions.width = '{"windowA": 1200, "windowB": 1000}', which we do in some places in Firefox IIRC. If we need this, can we have some sort of reference system? I think the key-value layout is pretty flexible, and if we do need scoped preferences, that could potentially solve that.
• In memory with notifications sounds good; for our frontend perspective, this is inline with everything else being asynchronous and decoupled. Things like an initial cache of current prefs, or a subset of commonly-accessed prefs, or startup prefs and updating via notifications, or requesting an uncached preference should all (IMO) live in the consumer's (electron frontend) domain. Yes windows can get out of sync, but will catch up eventually (~1s) and traditionally we haven't used preferences for any realtime/quick updating features. This is all more 'webby', and how frontend applications are structured with client/server architecture, or even backend-as-a-service things like Firebase have a similar subscription model.
• Firebase's client is a write-back cache (so "offline" is quite magical, as the UI can update from writes that have yet to make it to the server) which is very pleasant to work with/experience, and I think Firefox is a write-around cache style which in effect is a slower-to-update form of the Firebase client experience, but won't have offline issues anyway. Either way, this (IMO) should be outside of the UAS domain and handled by the frontend/UAS client

[rnewman]

Capturing some notes from Slack discussion:

• We have multiple writers and readers working asynchronously. (That's not the same as Firefox, which uses a single flushing write-back cache, but we are exposing some fundamental concerns about data storage that are shared!)
• In some cases we will want to know when a write succeeded or failed, and act on it (e.g., for rollback of state).
• In some cases subsequent writes, and changes outside of prefs, will depend for consistency on earlier writes having succeeded.
• In some cases we will be OK with optimistically acting as if a write immediately succeeded, at least within the same window. In other cases we don't want to be optimistic.

The likely best way to build prefs is with an in-memory write-around cache in each window. Each write to the UAS is generic, can succeed or fail, and by default updates the cache afterwards. Callers can optionally optimistically write to the cache immediately if they wish. Reads are fast after init.

The simplest UAS implementation of this is very little more than a generic write API and vocabulary, which is nice: that proves out a concept!

If we ever need non-local optimism — that is, a change is visible to other windows before it has been committed to disk — then we would need to introduce a cache or a different storage backend in the UAS. (This would be very relevant to Marco Bonardo's interests.)

Steps:

0. Vocabulary, scoping out how we model prefs.
1. UAS read and write API exposed to Tofino. We'll file a separate issue for that.
2. Exposing change listeners. (See https://github.com/mozilla/datomish/issues/61)
3. Tofino prefs UAC.
4. Tofino prefs cache.
5. Optional: synchronous prefs reads. (There are some sharp edges here around init.)
6. Optional: UAS-side prefs cache if needed for write-back or read perf. This is just a special case of the kinds of materialized views we want in Datomish anyway…

[rnewman]

Global seems like the safer option, as we can always model in scoped prefs via that, like branching: window.dimensions.width = '{"windowA": 1200, "windowB": 1000}', which we do in some places in Firefox IIRC.

I think I agree with you in principle, but in practice you're exposed to read-write atomicity races. We would need to expose alter! and swap! operations on prefs if we chose this kind of nested modeling.

Another way to do it is:

window.A.dimensions.width

which is safer…

[rnewman]

A perhaps more Datomishey way of doing this is:

101 :window/id "A"
101 :prefs/prefs 102
102 :prefs/window.dimensions.width 1200

with the query to find A's width:

[:find ?width . in $ :where
  [?window :window/id "A"]
  [?window :prefs/prefs ?prefs]
  [?prefs :prefs/window.dimensions.width ?width]]

[jsantell]

The likely best way to build prefs is with an in-memory write-around cache in each window. Each write to the UAS is generic, can succeed or fail, and by default updates the cache afterwards. Callers can optionally optimistically write to the cache immediately if they wish. Reads are fast after init.

This sounds great to me -- as a follow up/clarity of our discussion, we can flag writes as write-back for more cosmetic preferences, like write(key, value, { optimistic: true }) if we need speed and less of an issue of failure. As each write can succeed or fail, if an 'important operation' occurs, we can catch that write's failure and decide how to handle it on per-write basis (assuming after the client does due diligence and reattempts if possible).

Another way to do it is:

Agreed on your comments on scoping -- if we can have dynamic branches (so a window ID as a substring of the preference name), this sounds great. In terms of window.A.dimensions.width versus Datomishey-way, I have no preference (and a Datomish newb).

If we ever need non-local optimism — that is, a change is visible to other windows before it has been committed to disk — then we would need to introduce a cache or a different storage backend in the UAS. (This would be very relevant to Marco Bonardo's interests.)

This seems significantly more complicated -- hopefully we won't have a use for this anytime soon!

[rnewman]

This seems significantly more complicated -- hopefully we won't have a use for this anytime soon!

Yeah, that's one reason I'm defaulting to just using the Datomish store — it's less complicated, it gets us a general API, and it allows us to do things like blur the lines of what's a "preference" versus "data", have queries match against preferences, and include pref changes in the transaction log.

In terms of window.A.dimensions.width versus Datomishey-way, I have no preference (and a Datomish newb).

One reason to do this with fixed keys (and hierarchically so) is that it allows us to model preferences as data. That is: they would have a schema, the schema would be in the store, you could mark individual preferences as noHistory, you could full-text query preferences… at that point, "preferences" simply means "the data that windows keep in memory for simple lookups", and it's really no different to any other cache — it's just like the set of toolbar bookmarks, for example.

[rnewman]

The downside of using fixed keys is that you need to define prefs before you use them, and you can't use computed keys.

That said, computed keys (and often JSON values) are really just a hack that we use to store structured data in a non-structured key-value store, so I suspect we won't need them.