Intent to Implement: Bucket of proposed Indexed DB "level 2" features

[Joshua Bell]

Contact email:

jsb...@chromium.org

Spec: 

A few of the items in these notes from a Google/Mozilla meeting: https://docs.google.com/document/d/1vvC5tFZCZ9T8Cwd2DteUvw5WlU4YJa2NajdkHn6fu-I/edit?usp=sharing - e.g. IDBCursor.continuePrimaryKey, IDBIndex.openCursor(primary key), IDBObjectStore.openKeyCursor(), IDBObjectStore.getAll(), binary keys, storage type, window.onerror integration.

We haven't tackled "level 2" spec logistics (e.g. relicensing and doing it under WHATWG, etc) yet. That's on my to-do list as well.

Summary:

A handful of incremental Indexed DB features with rough consensus from Mozilla that they would be good platform additions. Some have had public API discussions [1], most "fairly obvious" but we'd like real developer feedback.

Motivation:

These address real developer feedback. All have been feature requests by users of the existing API, tracked via the W3C bug tracker [2]

Compatibility Risk:

Changes would be additions; we're prototyping some (e.g. "continuePrimaryKey"), Moz is prototyping others (e.g. multi-get). Rough plan is to then compare notes, then figure out formal spec strategy, and have agreement and/or compatible implementations before dropping the flag.

We'd only tackle additions that retain current behavior (i.e. new method is not present, new data type throws error) if the --enable-experimental-web-platform-features flag is unset. One exception might be window.onerror integration - additional members/bubbling on events from existing APIs that seems relatively innocuous, and in line with things we've done like IDBVersionChangeEvent.dataLoss.

Ongoing technical constraints:

None - scoping this "intent to implement" to just incremental items. (i.e. "redo the whole API using Promises is out of scope")

OWP launch tracking bug:

None.

Link to entry on the feature dashboard:

None - we should add one when there's a more concrete spec for IDB "level 2" rather than just a bucket of little experimental additions.

Requesting approval to ship?

No. We would probably wait until we've sync'd with Mozilla and have compatible implementations behind flags.

[1] http://lists.w3.org/Archives/Public/public-script-coord/2013JulSep/0490.html

[2] https://www.w3.org/bugzilla_public/buglist.cgi?order=Importance&resolution=LATER&query_format=advanced&bug_status=RESOLVED&component=Indexed%20Database%20API&product=WebAppsWG

[Eric Seidel]

I'm inferring from your email that you plan to implement this behind a
flag. If so, this sounds awesome. :)

[Joshua Bell]

On Fri, Sep 20, 2013 at 4:12 PM, Eric Seidel <ese...@chromium.org> wrote:

I'm inferring from your email that you plan to implement this behind a
flag.  If so, this sounds awesome. :)

Yep. Everything would be behind  --enable-experimental-web-platform-features, except maybe window.onerror integration (might not be worth the hassle)

[Adam Barth]

On Fri, Sep 20, 2013 at 5:00 PM, Joshua Bell <jsb...@google.com> wrote:

On Fri, Sep 20, 2013 at 4:12 PM, Eric Seidel <ese...@chromium.org> wrote:

I'm inferring from your email that you plan to implement this behind a
flag.  If so, this sounds awesome. :)

Yep. Everything would be behind  --enable-experimental-web-platform-features, except maybe window.onerror integration (might not be worth the hassle)

Sounds great.

Adam

[kyaw...@gmail.com]

store.createIndex(name, keypath, {filter: expression})

It is available behind the flag? That will be awesome.

Kyaw

[Joshua Bell]

On Sat, Mar 22, 2014 at 9:05 PM, <kyaw...@gmail.com> wrote:

store.createIndex(name, keypath, {filter: expression})

It is available behind the flag? That will be awesome.

Nope - we haven't made progress on that one. The items behind the flag at the moment are:

IDBObjectStore.openKeyCursor()

IDBCursor.continuePrimaryKey()

and (if the flag is set) you can use Uint8Arrays as keys.

[Eric Seidel]

Generally each feature gets its own toggle in Blink's RuntimeEnabledFeatures.in:
http://blink.lc/blink/tree/Source/platform/RuntimeEnabledFeatures.in
The ones which are marked there as "experimental" will automatically
be enabled by Chromium's --enable-experimental-web-platform-features
command line flag.

RuntimeEnabledFeatures are cheap to create and allow us to have a
single point by which we can turn off features on Beta/Stable channels
if things go wrong.

Then again, I'm pretty sure I'm preaching to the choir and you already
understand this all. :)