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

On 31 March 2011 12:41, 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.
> 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.


Stateless indexes can be provided differently to how you suggest. You can
have a 'validate_index' call that checks the index exists and creates it if
it does not. It is stateless in the sense that you call that to open
existing index or create one, you dont care if the database has one already
or not.

Infact you can make SQL stateless by providing a "validate_schema" call that
succeeds if the schema of the database matches the passed schema, can be
modified with no data loss to be the same, or needs to be created.

The RelationalDB wrapper for WebSQL provides this kind of stateless approach
for SQL... you can check it out on github if you like (its a work in
progress though):

https://github.com/keean/RelationalDB


Cheers,
Keean.