Data storage for remote content whitelist

David Bienvenu dbienvenu at
Wed Sep 7 17:48:52 UTC 2011

We're going to need to be able to sync data in all kinds of data stores,
so this is more of a question of how efficiently we can do sync of a
particular data store. For small data stores like filter files, prefs,
etc, just copying the whole file should be fine, but for larger stores,
change sets would be much more efficient. If the underlying store has a
way of representing change sets, that would be a win, but otherwise,
we'd need to implement it at the application level.

- David

On 9/7/2011 1:16 AM, Jb Piacentino wrote:
> Following up on David Ascher's comment, and more as a heads up than
> anything else:
> One direction we would like to explore is to deliver a Thunderbird
> 'experience' on multiple devices, ie desktop, web and mobile (ie touch
> devices) access to the same set of data. 'Experience' says it all:
> what should that be remains to be defined. But in this perspective,
> data sync (not only AB, but white/black lists, settings, credentials,
> and maybe not email....) should be very central.
> Jb
> On 06/09/2011 22:34, 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).
> _______________________________________________
> tb-planning mailing list
> tb-planning at

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the tb-planning mailing list