W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2014

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

From: Jonas Sicking <jonas@sicking.cc>
Date: Fri, 18 Apr 2014 11:30:10 -0700
Message-ID: <CA+c2ei9QBraA5Y=x35uugUyyh3f0f_H+eSho=D5qCkniumdy6g@mail.gmail.com>
To: Domenic Denicola <domenic@domenicdenicola.com>
Cc: Joshua Bell <jsbell@google.com>, Tim Caswell <tim@creationix.com>, "public-webapps@w3.org" <public-webapps@w3.org>, Ali Alabbas <alia@microsoft.com>
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
Received on Friday, 18 April 2014 18:31:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:24 UTC