<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>