Dear lazy -moz-web,
By Jonathan Protzenko on Thursday, December 16 2010, 22:30 - mozilla - Permalink
Ha! Now I'm on Planet I get to write "Dear lazyweb" posts too ;-).
More seriously, I recently faced the following problem. For Thunderbird Conversations, I need to store the quick reply state for each conversation. It's kind of like a draft, except it's tied to a given conversation, and doesn't show up as a regular draft in the Drafts folder. I have a unique id for each conversation, so all I need is a simple system for storing key/value pairs. Keys are the conversation unique ids, and values are the composition parameters (body text so far, recipients...).
localStorage seemed to do the trick, although I had to go the XPCOM way since I'm chrome. I used a trick found in a mochitest. However, this is synchronous and blocks the main thread, and I seriously don't want to do that.
I've ruled out the following solutions already:
- toolness' CouchDB-in-browser, because it's based on localStorage so it does IO on the main thread,
- indexedDB, because it's only available for content (bug 587797)
- localStorage, for the reasons outlined above.
After discussing this intensively with sdwilsh, I came up with conclusion that I need to use the mozStorage async API. Since SQL sounds overkill for me (I won't be doing any advanced queries), I figured out I might as well write a wrapper on top of it that exposes a simple localStorage-like API, with just get/set actions. In short, I need:
- a key/value storage system
- that's asynchronous, and does not block the main thread,
- that's usable from chrome.
So I'm going to start writing that wrapper, although I'm surprised no one has done that before. So could anyone tell me if I'm about to reinvent the wheel?
Thanks!
Comments
Your extension runs in a content document; you have moz_indexedDB available. I can see it with DOM inspector!
Er, since I didn't have localStorage (the property exists but accessing it raises an exception) and since there was that bug about not being able to access it from chrome (and my content is a chrome:// URI), I figured out the code would throw an exception at my face as well.
I probably looked for indexedDB, not moz_indexedDB.
I think I'm going to use this, thanks Andrew!
Caveat: I did not actually test whether I could make it do things. Maybe it explodes too? I just know that Jetpack having a bug about needing a feature is frequently just a bug about not having a way to get at things outside of an HTML content document (which could have chrome or non-chrome privileges).
If it does explode, on the jetpack list I think someone announced a pretty thin shim over mozStorage for async purposes. (nb: I think it had some issues and they might not have been resolved.)