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: Joran Greef <joran@ronomon.com>
Date: Thu, 31 Mar 2011 14:41:36 +0200
Cc: public-webapps@w3.org
Message-Id: <5A3CB174-CADC-4736-82F0-D384583BC456@ronomon.com>
To: Keean Schupke <keean@fry-it.com>
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.
2. Treat objects as opaque (remove key path, structured clone mechanisms, 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).
3. Remove setVersion (redundant, application migrates objects and indexes using transactions as it needs to).
4. Remove createIndex.

This would rip so much from the spec as to reduce it to a bunch of tatters, defining nothing more than an interface for index/key/value primitives in terms of well-established interfaces.

Essentially, we need LocalStorage with asynchronous IO (based on Node's callback style), large quota support, and a BTree API. Failing that, a decent FileSystem API on which to build these.
Received on Thursday, 31 March 2011 13:01:58 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:30 UTC