On 04 Apr 2011, at 6:10 PM, Mikeal Rogers wrote: > it's not very hard to write the abstraction you're talking about on top of > IndexedDB, and until you do it i'm going to have a hard time taking you > seriously because it's clearly doable.
You assume I have not written the abstraction I am talking about on top of IndexedDB? > the constructs in IndexedDB are pretty low level but sufficient if you know > how to implement databases. performance is definitely an issue, but making > these constructs faster would be much easier than trying to tweak an off the > shelf SQL implementation to your use case. How exactly would you make a schema-enforcing interface faster than a stateless interface? How would you implement application-managed indices on top of IndexedDB without being slower than SQLite? How would you implement set operations on indices in IndexedDB without being slower or less memory efficient than SQLite? How would you create an index on an existing object store in IndexedDB containing more than 50,000 objects on an iPad, without incurring any object deserialization/serialization overhead, without being an order of magnitude slower than SQLite, and without bringing the iPad to its knees? If you can do it with even one IndexedDB implementation out there then kudos and hats off to you. :) I understand your point of view. I once thought the same. You would think that IndexedDB would be more than satisfactory for these things. The question is whether IndexedDB provides adequate and performant database primitives, to the same degree as SQLite (and of course SQL is merely an interface to database storage primitives, I do not recalling saying otherwise). You can build IndexedDB on top of SQLite (as some browsers are indeed doing), but you cannot build SQLite on IndexedDB.
