Re: [IndexedDB] Design Flaws: Not Stateless, Not Treating Objects As Opaque

On 31 March 2011 08:38, 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. 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.
>

I totally agree with everything so far...


> 3. This requires an adjustment to the putObject and deleteObject interfaces
> (see previous threads).
>

I disagree that a simple API change is the answer. The problem is
architectural, not just a superficial API issue.


Cheers,
Keean.