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: Keean Schupke <keean@fry-it.com>
Date: Thu, 31 Mar 2011 17:41:21 +0000
Message-ID: <AANLkTimOmCiMLDFudYWsXcWeLfp_3pf8EmuVuQ2E-J5U@mail.gmail.com>
To: Jeremy Orlow <jorlow@chromium.org>
Cc: Joran Greef <joran@ronomon.com>, public-webapps@w3.org
On 31 March 2011 17:27, Jeremy Orlow <jorlow@chromium.org> wrote:

> 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
> flexibility.
>
>
>> 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.
>
> J
>

Surely intent should be only to do what is necessary in the browser, and to
do the rest in a library. So for me convenience functionality should be
provided by libraries. Only that which has to be done in the browser should
be done in the browser?

Cheers,
Keean.
Received on Thursday, 31 March 2011 17:41:54 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:43 GMT