On 06 Apr 2011, at 2:53 AM, Pablo Castro wrote: > The goal of IndexedDB has always been to enable things like RelationalDB and > CouchDB to be built on top, while maintaining a reasonable level of > functionality for those that wanted to use it directly. I really like the > idea of thinking of RelationalDB as something that's built as a library on > top of IndexedDB. Are there specific tweaks we can make to IndexedDB so it > can be a good lower-layer for RelationalDB, such that RelationalDB could be > built as a pure JavaScript library? > > Thanks > -pablo
1. Treat object values as opaque (necessary to avoid deserialization/serialization overhead, this is mandatory for storing anything over 50,000 objects on a device like an iPad or iPhone). 2. Enable indices to be modified at time of putting/deleting objects (index references provided by application at time of putObject/deleteObject call). 3. Provide a simpler, more powerful locking mechanism, opaque to IndexedDB, to provide finer-grained application-specific locking (i.e. have we just entered into a sync process with the master database). If I may say so, it does seem odd that some would advocate the difficulties of speccing merely the interface of something like SQLite, and then advise others to suggest re-implementing it entirely. If there was a specific BTree API in the browser and a powerful asynchronous sLocalStorage mechanism this might be something for the brave, but IndexedDB is a little too tightly coupled to it's own interface agenda at the moment to make this goal possible.
