From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Jeremy Orlow Sent: Friday, December 10, 2010 7:27 AM >> >> In addition to createObjectStore, I also intend to convert the following >> over: >> >> >> IDBObjectStore.createIndex >> IDBObjectStore.openCursor >> IDBIndex.openCursor >> IDBIndex.openKeyCursor >> IDBKeyRange.bound
Sounds great. >> We did all of these two weeks ago in Chromium and have gotten some feedback. >> The main downside is that typos are silently ignored by JavaScript. We >> considered throwing if someone passed in an option we didn't recognize, but >> this would make it impossible to add more options later (which is one of the >> main reasons for doing this change). I think what we might do is just log >> something in the console with this happens. (Should the spec actually make >> a recommendation to this effect?) Besides that, I think overall we're happy >> with the change. I'm not sure what the problem is with throwing. Can't each implementation throw if it receives a parameter that has no meaning for it? Given that we can't know if future options will have substantial impact on the behavior of the function when they are present, it looks safer to go that route. Is there prior art in some other webapps API that takes JavaScript objects as parameters? What do they do? Thanks -pablo
