704 karma · joined February 26, 2008
The trick with Datomic is that every time you grab a `db` instance, it's a snapshot, and the system's index chunking and storage replication are necessarily built around the ability to continue using those older index chunks, potentially for a very long time.
Most consumers, most of the time, just want to query the store as it stands at that moment, but Datomic peers pay the space and time penalty of keeping and retrieving historical index chunks in order to answer those historical queries.
My current thoughts are:
1. To allow for short-term snapshot querying through something like `db.keep()`, implemented via a SQLite read transaction. That's not free: the database WAL will continue to grow until the read transaction is ended, so it isn't ideal for all workloads, but it'll do.
For some queries it's enough to simply track a last-seen tx value and filter everywhere, but that becomes difficult when cardinality-one and unique-identity properties are considered.
2. The obvious equivalent to Datomic's 'with' is an uncommitted write transaction. Naturally this blocks other writers while it exists, and so alternative implementations (e.g., writing to a complete disk copy of the database, or writing a 'delta' table) might make sense.
At some very hazy point in the future we might try to get SQLite support for this: after all, if we can guarantee that a write transaction won't be committed, we could use a separate WAL file for the `with` and avoid blocking other writers.
3. A longer-term approach to snapshots/DB-as-value is to materialize the datoms at the specified instant in time, either in a temporary table or in a real persisted table. That is: `db.keep_forever()` will give you a new structure to query, and calling code will be responsible for cleaning up that space.
The reason I say "won't be free" is that each of these operations imposes a cost when the feature is used: either SQLite or Mentat will have to do some work to allow an extended period of isolation, to reconstruct some state, or to persist some state.
That's in contrast to Datomic, which imposes some overhead every time index chunks are built or retrieved. It's also an interesting parallel to Clojure vs Rust: Clojure's data structures are persistent by default, giving you snapshots and safety at a cost everyone pays; Rust believes that you shouldn't pay for abstractions you don't use.
We are several months from that, though!
Datomic's model (both architectural and conceptual) draws from Clojure's concepts of persistence. That model isn't free, so Mentat deviates from it where it makes sense to do so: at present we don't implement querying of history or past states, for example, and when we do it won't be free.
We'll get closer to full Datomic-style datom store capabilities over time, but we'll make different performance tradeoffs.
https://medium.com/project-tofino/introducing-datomish-a-fle...
Most non-trivial applications will at some point call out into code written in C, or compiled from some other language. So what?
Widespread adoption a la SQLite is not one of our goals.
Rust meets our goals just fine… and it also produces demonstrably more correct software than C, which is important to us. (Not to mention leveraging the borrow checker and data race avoidance to provide safe near-automatic parallelization, which is a neat trick that's not in C's quiver.)
I would rather build Mentat in Swift or JavaScript than in C.
The original implementation was in ClojureScript. This reimplementation is in Rust, and is intended to work anywhere you can run Rust code: inside Node, inside Firefox, and in standalone applications.
We expect a WebExtensions API to wrap this inside Firefoxes at some point, but right now we're focused on the core (re)implementation.
Mozilla hasn't been a product brand for a long time.
If you can grab an adb log, come post it in #mobile on irc.mozilla.org.
The goal of session restore is to restore your session -- your open tabs should come back, the same pages should load, scrolled to the same place, and with the right content.
Then an hour of writing good tests.
Then lots of manual and automated testing on four or five platforms, and fixing the weird issues you get on Windows XP SP2, or only on 64-bit Linux running in a VM, or whatever.
Then making sure you don't regress startup performance (which you probably will unless you have a really, really slow disk).
Then implementing rock solid migration so you can land this in Nightly through to Beta.
Then a rollback/backout plan, because you might find a bug, and you don't want users to lose their session between Beta 2 and Beta 3.
Large-scale software engineering is mostly not about writing code.
(Source: I'm one of the engineers.)
(I work on Firefox for Android and iOS, and even _I_ don't really care which rendering engine it uses. I care that I can trust it, that the UX is excellent, and that I have my data.)
In theory we could ship a hotfix that steals those, and still could; we wouldn't need to do it via the FxA content JS, which would only get to see them during account creation.
There is no such thing as perfect security.
From the perspective of the underlying web engine, we're two separate browsers.
We've identified that XUL is a growing impediment to Firefox's continued success. Exactly what that means (there are dozens of reasons and dozens of ways forward), and how we're going to tackle it, is a big topic that we're digging into.
Yes, removing XUL implies that XUL-based add-ons are not going to last forever. That doesn't mean there won't be a path from here to there: everyone involved recognizes that add-ons are important, and we're increasingly going to be shipping parts of Firefox itself using add-on mechanisms.
And I haven't seen anyone seriously consider killing Gecko: it continues to be awesome, and one of the motivations for deXULification is to allow our platform developers the freedom to only focus on supporting HTML UIs, not a mix of HTML and XUL.
UA overrides are not the only tool in our toolbox. They're deployed in concert with outreach from webcompat.
UA overrides are a way of breaking a cycle, not preserving it.
They make it feasible for Japanese users to use Firefox without manually messing around with UA overrides (e.g., using Phony). And that gives us leverage. And with leverage our excellent webcompat team can get sites to make changes.
Did you file a bug?
We're using GitHub for ease of integration with CI systems, convenience, and the ability to move more rapidly. We'll move into m-c if and when it suits the needs of the project.