W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2011

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

From: Jeremy Orlow <jorlow@chromium.org>
Date: Thu, 31 Mar 2011 10:27:08 -0700
Message-ID: <AANLkTimNsNX9saH3VuNdWLOYYjAjHaUMB4XLbOMDB0_T@mail.gmail.com>
To: Joran Greef <joran@ronomon.com>
Cc: Keean Schupke <keean@fry-it.com>, public-webapps@w3.org
On Thu, Mar 31, 2011 at 5:41 AM, Joran Greef <joran@ronomon.com> wrote:

> On 31 Mar 2011, at 12:52 PM, Keean Schupke wrote:
> > 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.
> Yes, for IndexedDB to be stateless with respect to application schema, one
> would need to:
> 1. Provide the application with a first-class means to manage indexes at
> time of putting/deleting objects.

I'm OK with doing this for v1 if the others are.  It doesn't seem like that
big of an addition and it would give a decent amount of additional

> 2. Treat objects as opaque (remove key path,

Key paths are quite useful.  I agree that making it possible to use
statelessly is good, but I don't see any reason why making it 100% stateless
should be a goal.

> structured clone mechanisms

For sure, not going to happen.

> , application must provide an id and JSON value to put/delete calls,
> reduces serialization/deserialization overhead where application already has
> the object as a string).

I'm not sure why you think this would reduce overhead.

> 3. Remove setVersion (redundant, application migrates objects and indexes
> using transactions as it needs to).
> 4. Remove createIndex.

Like I said above, although I think we should make it possible to operate
more statelessly, I don't see a reason we need to remove stuff like this.
 Some users will find it more convenient to work this way.

Received on Thursday, 31 March 2011 17:27:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:17 UTC