RE: [IndexedDB] Spec changes for international language support

From: keean.schupke@googlemail.com [mailto:keean.schupke@googlemail.com] On Behalf Of Keean Schupke
Sent: Tuesday, March 22, 2011 5:34 PM

>> IMHO not the job of Idb to store the callbacks, so I don't see this complexity as a reason not to implement the API using callbacks. I think having one consistent API is more important.
>> Specifying the collation 'name' has all the same problems as callbacks (needs to be re-done on every page, possibility of using different collations on different pages).
>> Really a 'function' is just a symbol for a collation. A function name, is a better symbol for a collation than a string. Function's have a uniqueness property strings do not. So specifying a function as the >> collations instead of a string really is the same thing. Consider below:

I don't think it's the same. If we don't store the callbacks in the database it means every page has to have full knowledge of the database schema (at least all the indexes) all the time, instead of just pulling that in on demand when needed. It also means we can never allow browser developer tools or generic dev-tool-webpages to modify the database because indexes would become invalid (not sure allowing tools to mess with the database in general is a good idea, but I thought it illustrated the point well). 

I wonder if the overall issue we're discussing has to do with "how embedded" the database is. In BDB scenarios where the database is completely invisible outside of an application many of these decisions make more sense. I don't think of web applications that way. I think of them more as a number of building blocks (pages, pieces within pages, tool pages added on the side) that are authored and sometimes even versioned independently, and the interface between those building blocks and the store is public and visible to tools and generic data browsers. All that changes the assumptions in the overall picture.  

-pablo

Received on Wednesday, 23 March 2011 01:13:38 UTC