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

On Thu, Mar 31, 2011 at 12:16 AM, Joran Greef <joran@ronomon.com> wrote:

> On 31 Mar 2011, at 1:01 AM, Jonas Sicking wrote:
>
> > Anyhow, I do think that the idea of passing in index values at the
> > same time as a entry is created/modified is an interesting idea. And I
> > have said so in the past on this list. It's definitely something we
> > should consider for v2.
>
> > Oh, and if we did this, I wouldn't really know how to support things
> > like collations. Neither if you did collations using built in sets of
> > locales (like in Pablo's recent proposal), nor if you used some sort
> > of callback to do collation.
> >
> > / Jonas
>
> That's fine. You don't need to figure it out. Just look at how stateless
> databases have done it (or not done it) and do likewise.
>
> I submit to you that there is inadequate understanding of the concerns
> raised, hence the lack of urgency in trying to address them. That there is
> even a need for a "V2" is symptomatic of this.
>
> It may be a good idea to start looking at these things not as "interesting
> ideas" but as essential database concepts.
>
> If someone were trying to build some kind of transactional indexed key
> value store for the web, and they wanted to do a truly great job of it, they
> would certainly want to learn everything they could from databases that have
> made contributions to the field.
>

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?

J