0

I understand the limitations of QUOTA_BYTES_PER_ITEM and QUOTA_BYTES when using chrome.storage.sync. I'm finding them quite limiting for a annotated history related extension I am writing. I understand that local storage could avoid this problem, but I need a user to be able to maintain their data as they move to other devices or someday replace their machine. My question is - are their other storage methods to get around this? What about Google Keep? It is an extension, but it appears capable of a "unlimited" storage of notes, or at least far more than the limitations of chrome.storage.sync. Is it simply not playing by the same rules, or are there other methods I could be using? Currently I'm concatenating information into large strings in javascript and storing these using chrome.storage.sync. Then parsing that information later as my database. Thanks for any help!

Jon Pointer
  • 41
  • 5
  • Such extensions usually utilize an external service like dropbox, gdrive, mega, and so on. You can also compress the data using LZString or similar js library into a smaller UTF16 string. In any case extensions can't escape the limits of chrome.storage.sync, there's no magical method. If there were it'd be a superhuge hole in google's security which would be already fixed. – wOxxOm Aug 12 '19 at 04:23
  • @wOxxOm - Thank you for the LZString tip. I think I can greatly reduce my space by simplifying what I'm storing, breaking up my database into multiple blocks to make better use of QUOTA_BYTES_PER_ITEM and QUOTA_BYTES, and utilizing LZString. LZString will be a big help - thanks for that tip! – Jon Pointer Aug 12 '19 at 07:06
  • Here's a [usually] much faster fork: [LZString-unsafe](https://github.com/openstyles/lz-string-unsafe). – wOxxOm Aug 12 '19 at 08:28

0 Answers0