Amazing! Thanks @pat!

Looking at the indexeddb impl and maybe konserve model better fits to blobs at keys rather than objects? I have no evidence it would perform better, but filesystem impls already have similar io expectations. Was there a bottleneck you guys found that made you lose interest?

I cannot remember any. I worked on Indexeddb 5 years ago to be frank. It would be super cool if you could lift it to the current konserve framework. Feel free to elaborate a bit more about the design decisions between blobs and objects, I am not super familiar with it.

One annoying problem we have found (thanks to @U05095F2K) is that many browsers silently drop indexeddb, so we would have to treat it like a useful cache instead of actual durability in many cases.

I think you can put() https://developer.mozilla.org/en-US/docs/Web/API/Blob as values in the objectstore. You lose indexing + human readability but impl basically identical to fs code with same storage layout

I will take a crack at it

Awesome!

Do you have experience with CBOR btw.?

We started to play around with it a bit. It would be very nice because then we could also read our indices in other languages.

No & I haven't read up the full datahike stack yet, but it has occurred to me that a schema could improve read times. Is there a runtime in particular?

I looked into Julia for instance, https://github.com/JuliaIO/CBOR.jl. Python might also not be bad just for reach.

@pat This is not about optimizing deserialization times (which is another interesting topic), but more about generalizing Datahike beyond Clojure. There is the whole linked web and RDF out there, but using a Clojure specific format renders things very isolated from that.