RE: Starting work on Indexed DB v2 spec - feedback wanted

Speaking from the perspective of an IDB library author Promisification would be high on my list of wants as it was the primary driver behind my libraries existence.
 
The next thing would be function expression filtering, again this is something that my library attempts to solve (https://github.com/aaronpowell/db.js/blob/master/tests/specs/query.js#L543-L552) but has to do it in user space.
 
And to call out specific items from the IndexedDatabaseFeatures [1] it'd be Cancel versionchanged, Database Observers and batch-get's.
 
[1] http://www.w3.org/2008/webapps/wiki/IndexedDatabaseFeatures
 
Date: Sat, 19 Apr 2014 02:55:46 -0700
From: raynos2@gmail.com
To: jonas@sicking.cc
CC: domenic@domenicdenicola.com; jsbell@google.com; tim@creationix.com; public-webapps@w3.org; alia@microsoft.com
Subject: Re: Starting work on Indexed DB v2 spec - feedback wanted

> especially as your applicationgrows more complex or simply if the user has your application open in

two separate tabs.


The two tabs use case is an interesting point. Currently as I understand the leveldb interface avoids this problem by saying "only one process can open a database". 


Not quite sure what the best way a low level interface can handle this.


One valid option is to simply say "a database cant be opened by two tabs". This then requires a developer to use a cross tab communication channel to manually handle synchronization.

This enables the default interface to be race free.


On Fri, Apr 18, 2014 at 11:30 AM, Jonas Sicking <jonas@sicking.cc> wrote:

On Thu, Apr 17, 2014 at 2:04 PM, Domenic Denicola

<domenic@domenicdenicola.com> wrote:

> From: Joshua Bell <jsbell@google.com>

>> How much of leveldb's API you consider part of the minimum set - write

>> batches? iterators? snapshots? custom comparators? multiple instances per

>> application? And are IDB-style keys / serialized script values appropriate,

>> or is that extra overhead over e.g. just strings?

>

> This is my question for Tim as well. My personal hope has always been for

> something along the lines of async local storage [1], but that omits a lot

> of LevelDB's API and complexity, so presumably it goes too far for LevelDB

> proponents.

>

> [1]: https://github.com/slightlyoff/async-local-storage



A big question here is "do you need transactional integrity/atomic

mutations?" These things will always make the API more complex and so

it gets in the way if you don't need it. But not having them means

exposing yourself to race conditions, especially as your application

grows more complex or simply if the user has your application open in

two separate tabs.



My experience is that people need transactional integrity more often

than they think they do.



The API at [1] punts on transactional integrity entirely. It does not

allow you to perform complex operations like "increase the value at

'unreadEmailCount' by one" in a race-free manner.



/ Jonas