- From: Jonas Sicking <jonas@sicking.cc>
- Date: Fri, 18 Apr 2014 11:30:10 -0700
- 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