See my other comment, here: https://news.ycombinator.com/item?id=18297177
I'll explicate this in the documentation. Thank you for your feedback, bazizbaziz.
I recently tested localForage [0] to see if it could be more reliable and get around storage limitations of localStorage. Unfortunately, LocalForage has a very annoying problem where it picks a single storage backend to use, but the one it chooses can switch on page reloads (yes, even on the same device/browser.) and this switching causes data loss as keys stored in the other backends are unaccessible. I'm very interested to see if IronDB can help here! Thanks for working on this.
Don't hesitate to let me know if there's anything else I can help with, bazizbaziz.
I have a use case for this: I've written what is basically a crud web app for a non-profit. That's an offline app (appcache) and right now uses localstorage for keeping data offline in the browser while in the field. That is pretty brittle as is, but dedicated application installations didn't fit the budget. The app is used in the field by volunteers all over the country. With volunteers fluctuating and many people being privacy conscious, it happens regularly that they change Firefox preferences to delete cookies etc. on shutdown, and now newer Firefoxes deprecating localstorage, potentially resulting in data loss.
Something like IronDB would actually help me.
I'm not sure any of these properties are ensured the way anyone would want. Why do this? What are the failure modes this protects against? If only one of the backing stores is active when a result is written, and then the others later become active with no data, is blank data returned for the prior result? It seems like recording timestamps would fix this problem nicely on a single system and make this thing overall quite reliable.