ImmortalDB – A resilient key-value store for the browser

Re:ImmortalDB – A resilient key-value store for the browser by eridius on Monday January 28, 2019 @04:30PM (#19021260)

> And browsers will unceremoniously delete IndexedDB, LocalStorage, and/or SessionStorage without warning under storage pressure.

I get why it's doing this, but it strikes me as fairly user-hostile to react to the browser deleting data under storage pressure by duplicating the data so it now takes up 4x the space it used to.

[ Parent | on HN ]

Re:ImmortalDB – A resilient key-value store for the browser by sametmax on Monday January 28, 2019 @04:43PM (#19021370)

It's only for small chunks of data, since you have to limit yourself to the tiniest storage medium the browser allow for your replication.

E.G: on my browser, you can only store 81920 bytes per domain in cookies, so if I want the max redundancy, I have to limit myself to 80ko. Besides, cookies are sent in each request, so I want to limit myself. Let's say you want more, local storage is limited to 10 MB. It's not huge.

But the browser doesn't care about the size of the data, only how recent it is. So it may evict yours, even if it's very small, compared to the huge cache of hundred's of MB from the manifest file or the webworker from other open tabs.

[ Parent | on HN ]

Re:ImmortalDB – A resilient key-value store for the browser by woah on Monday January 28, 2019 @07:35PM (#19022619)

What if it is something small but very important. That seems like it would be the opposite of user-hostile.

[ Parent | on HN ]

Re:ImmortalDB – A resilient key-value store for the browser by mosselman on Tuesday January 29, 2019 @03:47AM (#19024802)

So it is not user-hostile when you don’t respect the user’s attempt to delete data? It seems condescending at the very least.

[ Parent | on HN ]