- From: Joran Greef <joran@ronomon.com>
- Date: Wed, 6 Apr 2011 06:33:43 +0200
- To: Pablo Castro <Pablo.Castro@microsoft.com>
- Cc: public-webapps@w3.org
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.
Received on Wednesday, 6 April 2011 04:34:15 UTC