3 ms·

What is the storage limit? Would be nice to offer some kind of helper function to return that. For instance, I want to store a base64 encoded image. I believe t

What is the storage limit? Would be nice to offer some kind of helper function to return that. For instance, I want to store a base64 encoded image. I believe there is a 10MB limit imposed by Chrome on local storage (or something similar). Bypassing that restriction locally would be great. Could be a nice feature of ImmortalDB.

tracker1 8y ago
That won't fit in cookie space... this is really for redundant controls for session/access tokens etc... anything large like that you're better off using caching and a service worker to handle repeated requests. Also, cookies are sent with every request to the server, and I don't think you'd want the user sending 10MB to your server for every request. Also, if you are storing larger strings in local/sessionStorage, websql or indexdb, you should use lz-string[1] to try to minimize storage impact. Aside: if you want something with a nicer interface for underlying storage you may want to look at pouchdb[2], which has a localized couch interface and supports remote synching to coudchdb, which is pretty nice. [1] https://github.com/pieroxy/lz-string https://github.com/pieroxy/lz-string [2] https://pouchdb.com/ https://pouchdb.com/
- martin_drapeau 8y ago
  Yeah, about those cookies - I don't want them (https://github.com/gruns/ImmortalDB/issues/6 https://github.com/gruns/ImmortalDB/issues/6). I just want to permanently store large data in the browser. ImmortalDB sounded like the right thing to abstract away everything and make it sticky.
  - dspillett 8y ago
    You can tell it not to use cookies, to get around the problems of them being more limited in size and being sent on each request so wasting bandwidth. I'm guessing a mix of localstorage and sessionstorage isn't al that useful (I can't imagine a circumstance where localstorage is being cleared when sessionstorage isn't also or hasn't already been) but localstorage+indexeddb might give you some useful level of protection.

tracker1 8y ago

That won't fit in cookie space... this is really for redundant controls for session/access tokens etc... anything large like that you're better off using caching and a service worker to handle repeated requests. Also, cookies are sent with every request to the server, and I don't think you'd want the user sending 10MB to your server for every request. Also, if you are storing larger strings in local/sessionStorage, websql or indexdb, you should use lz-string[1] to try to minimize storage impact. Aside: if you want something with a nicer interface for underlying storage you may want to look at pouchdb[2], which has a localized couch interface and supports remote synching to coudchdb, which is pretty nice. [1] https://github.com/pieroxy/lz-string https://github.com/pieroxy/lz-string [2] https://pouchdb.com/ https://pouchdb.com/

martin_drapeau 8y ago
Yeah, about those cookies - I don't want them (https://github.com/gruns/ImmortalDB/issues/6 https://github.com/gruns/ImmortalDB/issues/6). I just want to permanently store large data in the browser. ImmortalDB sounded like the right thing to abstract away everything and make it sticky.
- dspillett 8y ago
  You can tell it not to use cookies, to get around the problems of them being more limited in size and being sent on each request so wasting bandwidth. I'm guessing a mix of localstorage and sessionstorage isn't al that useful (I can't imagine a circumstance where localstorage is being cleared when sessionstorage isn't also or hasn't already been) but localstorage+indexeddb might give you some useful level of protection.