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: [email protected] To: [email protected] CC: [email protected]; [email protected]; [email protected]; [email protected]; [email protected] 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 <[email protected]> wrote: On Thu, Apr 17, 2014 at 2:04 PM, Domenic Denicola <[email protected]> wrote: > From: Joshua Bell <[email protected]> >> 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
