Data storage for remote content whitelist

Jb Piacentino jb at mozilla.com
Wed Sep 7 08:16:59 UTC 2011


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).
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/tb-planning/attachments/20110907/8c4fcd66/attachment.html>


More information about the tb-planning mailing list