Skip to content

Instantly share code, notes, and snippets.

@maxogden maxogden/readme.md
Created Apr 18, 2014

Embed
What would you like to do?
indexeddb v2 API feedback

(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.

@karlcow

This comment has been minimized.

Copy link

commented Apr 18, 2014

Did you see the

Mail actions: [ respond to this message ]

in the footer?

@maxogden

This comment has been minimized.

Copy link
Owner Author

commented Apr 18, 2014

@karlcow yes. As I do not have a mailto: handler installed (I use gmail.com) I first tried right clicking the link and selecting 'copy address', which gave me public-webapps@w3.org instead of the full url, which I was only able to get by inspecting the HTML in dev tools:

public-webapps@w3.org?Subject=Re%3A%20Starting%20work%20on%20Indexed%20DB%20v2%20spec%20-%20feedback%20wanted&In-Reply-To=%3CCAD649j7hbxHs39-qPPC9Swr5kYj1SGr4XZvVN-j1N%2BXeYEZfdw%40mail.gmail.com%3E&References=%3CCAD649j7hbxHs39-qPPC9Swr5kYj1SGr4XZvVN-j1N%2BXeYEZfdw%40mail.gmail.com%3E

Unfortunately gmail didn't recognize this as a vailid email, so I gave up.

@BrendanEich

This comment has been minimized.

Copy link

commented Apr 18, 2014

I like lower level APIs, too (http://extensiblewebmanifesto.org/), but talking about "storing data in batches" does not define the happens-before partial order among reads and writes, batched or unbatched. We need atomic transaction building blocks. Agree batching is important to amortize overhead.

/be

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.