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

> especially as your application
grows 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
>
>

Received on Saturday, 19 April 2014 09:56:14 UTC