> On 3/9/2011 09:45:51 Shawn Wilsher wrote: > > That makes sense since the original proposal was heavily based on BDB. > It's shifted a bit as we have made tweaks to improve it for the web. > > Cheers > > Shawn
I agree. If I may add my two cents worth: one thing that IDB has not yet learned from BDB is statelessness. At the moment IDB requires a bit of application state to be mixed up in IDB (i.e. by predefining indexes as opposed to allowing the application to specify indexes to be modified when putting or deleting objects). So it's not a pure data+indexes store, it's actually a data+indexes+application state store. This is making IDB more complex than it needs to be and is making the IDB interface less powerful (things like compound keys etc. would already be possible if IDB were stateless). For instance, if IDB is to store application state, then the spec needs to define what happens when the application state changes. If IDB were stateless, this would not be necessary. After the web having had no options for offline storage for so many years, it is probably safe to say that web applications do not need help with things like migrations, pre-defined schemas or anything fancy or "helpful" like that, they just need a pure data+indexes solution (but they need this to be comprehensive: at least set operations supported on indexes, and indexes defined by the application when putting or deleting objects and NOT before). In my honest opinion, IDB is not yet there and from the discussions does not seem to be headed in that direction. It's trying to make unnecessary things easy when it really needs to be just a powerful low-level data store with first-class indexing. I'm not sure how many users of IDB are actively involved in this discussion, but after spending hours on it over the past few months, and having built databases over LocalStorage and WebSQL, as a real-world user, may I ask that these concerns begin to be addressed?
