On 31 March 2011 17:27, Jeremy Orlow <[email protected]> wrote: > On Thu, Mar 31, 2011 at 5:41 AM, Joran Greef <[email protected]> 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.
