Data storage for remote content whitelist
dbienvenu at mozilla.com
Tue Sep 6 21:29:46 UTC 2011
Indexed DB is an other possibility -
I suspect sqlite is overkill, and that a json file is probably fine. I
don't see that this list should get very big. I would suspect that the
user would just turn on whitelisting of a whole address book/list
instead, if we supported that.
On the other hand, my understanding is we're moving it out of the AB so
that you don't need a card in the AB in order to whitelist someone. That
seems like that could be solved by having cards that don't show up for
normal purposes...perhaps something to consider when we redo the AB in
On 9/6/2011 1:34 PM, Irving Reid wrote:
> I've been speaking to Blake (bwinton) and Mark (standard8) about bug
> 457296, moving the "load remote content" white list out of the address
> book and into a separate place. This is the list of addresses for
> which the end user has clicked "always load remote content for
> messages from <email-address>".
> Mark suggested that I open a discussion on tb-planning about how to
> store the data; for the time being it's going to be a simple table of
> display names and email addresses.
> We don't currently have much data on how end users are using this
> list, how many entries it typically contains etc. We should probably
> add this to test-pilot or whatever other user activity gathering tool
> would be most appropriate.
> That said, we don't want to create another Mork database to hold this
> list, so I'm looking for some architectural direction about what to
> use. My first thoughts turned to sqlite, since that's what we're using
> for Gloda. It could also be done with a simple text format (JSON,
> perhaps), slurped into memory on first use and appended or rewritten
> for updates; this would be fine unless a user had many thousands of
> whitelist entries.
> Are there any other alternatives I should consider? The impression I
> get from others is that Mork and RDF are on their way out. The profile
> currently contains sqlite, RDF, xml, Mork, json, .js (prefs), .txt and
> .dat files (containing name=value text entries).
More information about the tb-planning