- From: Jeremy Orlow <jorlow@chromium.org>
- Date: Thu, 31 Mar 2011 10:27:08 -0700
- To: Joran Greef <joran@ronomon.com>
- Cc: Keean Schupke <keean@fry-it.com>, public-webapps@w3.org
- Message-ID: <AANLkTimNsNX9saH3VuNdWLOYYjAjHaUMB4XLbOMDB0_T@mail.gmail.com>
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
Received on Thursday, 31 March 2011 17:27:41 UTC