Intent to Experiment: KV storage built-in module + import maps

[Domenic Denicola]

Contact emails

dom...@chromium.org, hiro...@chromium.org, kou...@chromium.org, pwn...@chromium.org

Spec

https://wicg.github.io/kv-storage/

https://github.com/WICG/import-maps

Summary

KV storage (formerly "async local storage") is a new high-level API for an asynchronous key/value store, layered on top of IndexedDB.

Importantly, KV storage is our first experiment with shipping APIs as built-in modules, instead of putting them on the global namespace. This brings along the need for new technology for controlling built-in modules. That is where import maps comes in.

Import maps provide the ability to control how JavaScript imports modules, including built-in modules. This allows polyfilling and virtualization of built-in modules, like developers do already with built-in globals.

We want to run an experiment with both of these features together, as they are coupled in interesting ways which we want to gain experimental feedback on. Import maps are more interesting when a built-in module, such as KV storage, exists to use them with. And KV storage is more useful to web developers when it can be polyfilled, which import maps allows.

Link to “Intent to Implement” blink-dev discussion

• For async local storage (former name of KV storage)

• For import maps

Note that we will only be experimenting with the subset of import maps discussed in that Intent to Implement.

Goals for experimentation

• Does the KV storage API meet developers' expectations and needs for key/value storage, enough to allow them to replace existing uses of sync localStorage or of large-ish async key/value store libraries?

• Do any of the open issues on KV storage, e.g. around rate limiting or allowed key types, show up in practice when using KV storage in production?

• Do import maps make it feasible to polyfill KV storage in production? (We plan to publish a basic polyfill at the start of the experiment, and invest in it more if there is developer interest.)

• Do import maps integrate well with modern JavaScript build tooling, e.g. bundlers, package managers, or module/nomodule builds?

• Is the syntax and developer experience of import maps usable and intuitive, or are there areas we could improve? (Including e.g. error messages, devtools integration, etc.)

Experimental timeline

M74 - M76

Any risks when the experiment finishes?

None. Although this is indeed an experimental storage API (which is literally the example given in the Intent to Experiment template), this API is layered on top of IndexedDB, so the data stays perfectly accessible!

In particular, a polyfill for KV storage can access the same IndexedDB databases that the built-in implementation creates, via the same API. Or, a developer could write hand-rolled IndexedDB code to access the data.

Ongoing technical constraints

None.

Debuggability

One interesting implementation artifact of our experimental implementation is that you can debug the JavaScript source code of the KV storage API using the devtools debugger. We are curious to find out if origin trial participants use this; if so, we may want to preserve this ability.

Otherwise, most of the DevTools-related concerns are about import maps, and are captured in that Intent to Implement.

Will this feature be supported on all five Blink platforms supported by Origin Trials (Windows, Mac, Linux, Chrome OS, and Android)?

Yes.

Link to entry on the feature dashboard

• For KV storage

• For import maps

[Chris Harrelson]

LGTM

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra8G1Gf5XU%3DKDSsu1%2BSotQMGvVJ0OM7aQPEdfbG%2B4Ck4hg%40mail.gmail.com.

[Jochen Eisinger]

Is this hooked up to content settings?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-RiVS1t5-uhoXCLQh3_pZ9ydZex48TaNW7pYicOn2LDA%40mail.gmail.com.

[Domenic Denicola]

On Tue, Mar 12, 2019 at 5:41 AM Jochen Eisinger <joc...@chromium.org> wrote:

Is this hooked up to content settings?

Talking with Jochen offline, I clarified that he meant the settings in chrome://settings/content/cookies for blocking site data. The answer is "yes"; since KV storage is layered on top of IndexedDB, instead of being a separate storage technology, it is automatically controlled in the same way.