(Intended as a response to http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0149.html but I don't know how to respond to the w3c mailing list)
I'd like to +1 the need for a lower level API. I'd be very happy to see effort go into developing standards for the following, simple use cases:
- Storing small, mutable data by key
- Getting ranges of keys (e.g. the leveldb iterator API)
- Storing data in batches (building block for transactions)
In a nutshell these represent the primitives in the LevelDB API, which are significantly less complex than IndexedDB. It's a shame that you have to de-abstract the IndexedDB API in order to get a LevelDB-esque API on top. This is just a thought experiment, but how awesome would it be if there was a LevelDB-esque API that IndexedDB itself used, but was also available as a separate, lower level API?
It seems to me that the IndexedDB API as it exists today was a product of a process that predates the Extensible Web Manifesto http://extensiblewebmanifesto.org/, especially the "Focus on adding new low-level capabilities" part.
Additionally, while definitely outside the scope of IndexedDB:
- Storing blobs by key, as a stream
- Getting blobs by key, as a stream
A way of handling the storage and retrieval of larger, immutable objects is sorely needed on the web today. Consider this library, level-filesystem: https://github.com/mafintosh/level-filesystem. It implements the entire Node FS API (http://nodejs.org/api/fs.html) on top of the node levelup API, which in turn works on top of the IndexedDB API in browsers via level.js.
If there was some way to efficiently stream large binary objects (blobs) in and out of persistent storage (stored by key), then combined with e.g. level-filesystem we could be building wayyyy cooler and faster web apps. We don't need a full virtual filesystem that will be hard to implement, but instead just a key value store that supports range queries and an additional simple blob store API.