<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
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.<br>
<br>
- David<br>
<br>
On 9/7/2011 1:16 AM, Jb Piacentino wrote:
<blockquote cite="mid:4E67287B.7090704@mozilla.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
Following up on David Ascher's comment, and more as a heads up
than anything else: <br>
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. <br>
<br>
Jb<br>
<br>
On 06/09/2011 22:34, Irving Reid wrote:
<blockquote cite="mid:4E6683F3.4020604@mozilla.com" type="cite">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>". <br>
<br>
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. <br>
<br>
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. <br>
<br>
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. <br>
<br>
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). <br>
<br>
</blockquote>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
tb-planning mailing list
<a class="moz-txt-link-abbreviated" href="mailto:tb-planning@mozilla.org">tb-planning@mozilla.org</a>
<a class="moz-txt-link-freetext" href="https://mail.mozilla.org/listinfo/tb-planning">https://mail.mozilla.org/listinfo/tb-planning</a>
</pre>
</blockquote>
<br>
</body>
</html>