Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Better persistent storage #1212

Closed
CAFxX opened this issue Nov 1, 2010 · 4 comments
Closed

Better persistent storage #1212

CAFxX opened this issue Nov 1, 2010 · 4 comments
Milestone

Comments

@CAFxX
Copy link

CAFxX commented Nov 1, 2010

A better backend for the GM_*Value could be a good idea.
In a couple of scripts I need to work on big persistent arrays and performance is sluggish, even using memoization.

@johan
Copy link
Collaborator

johan commented Nov 1, 2010

Have you considered and written off HTML5 storage as a non-viable option (i e because your script has to execute across domains)? If not, you can't get much better portability and future safety support than using the browser-native tools.

@arantius
Copy link
Collaborator

See: http://groups.google.com/group/greasemonkey-dev/t/8b82b4e5919b96dc

Patch from 2006 probably doesn't work anymore.

@DavidJCobb
Copy link

A private DOM Storage object, like those provided to Opera userscripts, would be a good idea -- especially if StorageEvents are implemented reliably. It'd allow for large data stores and easier synchronization between multi-tab userscripts, without leaking into or potentially interfering with storage code in the content scope.

@jerone
Copy link
Contributor

jerone commented Jan 22, 2014

This is fixed by #1798, using SQLite now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants