On 4/26/2013 12:10 PM, Benjamin Smedberg wrote:
> On 4/26/2013 2:50 PM, Gavin Sharp wrote:
>> On Fri, Apr 26, 2013 at 11:36 AM, Andreas Gal <g...@mozilla.com> wrote:
>>> Preferences are as the name implies intended for preferences. There
>>> is no sane use case for storing data in preferences. I would give
>>> any patch I come across doing that an automatic sr- for poor taste
>>> and general insanity.
>> As Greg suggests, that ship has kind of already sailed. In practice
>> preferences often ends up being the "best" choice for storing some
>> small amounts of data. Which is a sad state of affairs, to be sure -
>> so I'm glad we have this thread to explore alternatives.
> The key problem with expanding this is that the pref API is designed
> to be synchronous because it controls a bunch of behavior early in
> startup. Our implementation is therefore to read all the prefs in
> (synchronously) and operate on them in-memory. That strategy only
> continues to work as long as the set of data in prefs is tightly
> constrained.
Perhaps this should be advertised more, especially to the add-on
community. Looking at about:config of my main profile, about 2/3 of my
preferences are user set. There are hundreds of preferences apparently
being used for key-value storage by add-ons (not to pick on one, but
HTTPS Everywhere has a few hundred prefs).
This shouldn't be surprising: Preferences quacks like a generic
key-value store. In the absence of something similar and just as easy to
use, people will use (and abuse) it for storage needs.
IMO we can't just say "don't use Preferences for that" without offering
something equivalent. If we do, we'll have SQLite/raw I/O and we're no
better off.
> With a pretty simple JSM wrapper, indexeddb could be a very good
> solution for saving JSON or JSON-like things (you don't even need
> JSON, because indexeddb does structured cloning). It can of course be
> used for more complex things as well, but if we want a durable
> key-value store, it could be as simple as:
>
> ChromeData.get('key', function(value) {
> // null if unset
> });
>
> ChromeData.set('key', value [, function()]); // asynchronous
>
> Or maybe there's a better syntax using promises, but in any case it
> could probably be this simple.
I strongly believe a simple wrapper would go a long way. The current
pitfalls of storage have bitten me enough times that I'm tentatively
volunteering to add one to Toolkit.
However, before that happens, I'd like some consensus that IndexedDB is
the best solution here. I'd especially like to hear what Performance
thinks: I don't want to start creating a "preferred" storage solution
without their blessing. If they have suggestions for specific ways we
should use IndexedDB (or some other solution) to minimize perf impact,
we should try to enforce these through the preferred/wrapper API.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
