Re: [w3c/IndexedDB] Define flush-to-disk guarantees and control (#50)

### Aside

To clarify, Firefox's IndexedDB is built on top on SQLite and [since 2015](https://bugzilla.mozilla.org/show_bug.cgi?id=866846) has used its Write-Ahead-Log in `PRAGMA synchronous=NORMAL` mode ([SQLite docs](https://www.sqlite.org/pragma.html#pragma_synchronous)).  This is supposed to provide durability in the face of browser crashes but may rollback on device crashes.

### On the issue

I'd like to instead propose that we address this via [storage buckets](https://github.com/whatwg/storage/issues/2).  When creating a bucket, the site would specify what level of durability it wants the bucket to have (among other things).  This provides a ton of implementer latitude just beyond "do we do an fsync at the end", as well as providing a gateway to improved storage eviction and improved user control on what's being stored on their device.

Also, in the event corruption of a database happens (which realistically is a thing that can happen, although thankfully we're past some of the darkest days of this), it makes it easier to limit the spillover damage.  I think in theory, per spec, browsers would wipe the entire origin if any database in the origin became corrupt, but in practice I suspect they all just throw errors on the database until you delete it.  Buckets would help with this too.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/IndexedDB/issues/50#issuecomment-525474379