- From: Jeremy Orlow <jorlow@chromium.org>
- Date: Thu, 31 Mar 2011 10:13:53 -0700
- To: Joran Greef <joran@ronomon.com>
- Cc: public-webapps@w3.org
- Message-ID: <AANLkTinhQZByZUtc-1tzijcUTfnS-xwzZga6TV-A-Nzc@mail.gmail.com>
On Thu, Mar 31, 2011 at 1:38 AM, Joran Greef <joran@ronomon.com> wrote: > On 31 Mar 2011, at 9:34 AM, Jeremy Orlow wrote: > > > We have made an effort to understand other "contributions to the field". > > > > I'm not convinced that these are "essential database concepts" and having > personally spent quite some time working with the API in JS and implementing > it, I feel pretty confident that what we have for v1 is pretty solid. There > are definitely some things I wouldn't mind re-visiting or looking at closer, > possibly even for v1, but they all seem reasonable to study further for v2 > as well. > > > > We've spent a lot of time over the last year and a half talking about > IndexedDB. But now it's shipping in Firefox 4 and soon Chrome 11. So > realistically v1 is not going to change much unless we are convinced that > what's there is fundamentally broken. > > > > We intentionally limited the scope of v1, which is why we know there'll > be a v2. We can't solve all the problems at once, and the difficulty of > speccing something is typically exponential to the size of the API. > > > > Maybe a constructive way to discuss this would be to look at what use > cases will be difficult or impossible to achieve with the current design? > > Application-managed indices for starters That's not a use case. > I would consider that to be essential when designing indexed key/value > stores, and I would consider that to be the contribution made by almost > every other indexed key/value store to date. If we have to use IDB the way > FriendFeed used MySQL to achieve application-managed indices then I would > argue that the API is in fact "fundamentally broken" and we would be better > off with an embedding of SQLite by Mozilla. > > Regarding "the difficulty of speccing something is typically exponential to > the size of the API", if people want to build a Rube Goldberg device then > they must deal with the spec issues of that. > > If we were provided with the primitives for an indexed key/value store with > application-managed indices (as Nikunj suggested at the time), we would have > been well out of the starting blocks by now, and issues such as "computed > indexes", "indexing array values" etc. would have been non-issues. > > Summary: > > 1. There's a problem. > 2. It can still be fixed with a minimum of fuss. > 3. This requires an adjustment to the putObject and deleteObject interfaces > (see previous threads).
Received on Thursday, 31 March 2011 17:14:25 UTC