57/a304fcc64cd94542f3ea5391d4ba4c2ece8245

   1 Return-Path: <cworth@cworth.org>\r
   2 X-Original-To: notmuch@notmuchmail.org\r
   3 Delivered-To: notmuch@notmuchmail.org\r
   4 Received: from localhost (localhost [127.0.0.1])\r
   5         by olra.theworths.org (Postfix) with ESMTP id ABBB9431FBC\r
   6         for <notmuch@notmuchmail.org>; Thu, 14 Jan 2010 14:24:56 -0800 (PST)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: -1.916\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5\r
  12         tests=[ALL_TRUSTED=-1.8, AWL=0.069, BAYES_40=-0.185] autolearn=ham\r
  13 Received: from olra.theworths.org ([127.0.0.1])\r
  14         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  15         with ESMTP id Z+-c8ofK9AX8; Thu, 14 Jan 2010 14:24:56 -0800 (PST)\r
  16 Received: from yoom.home.cworth.org (localhost [127.0.0.1])\r
  17         by olra.theworths.org (Postfix) with ESMTP id DC2AB431FAE;\r
  18         Thu, 14 Jan 2010 14:24:55 -0800 (PST)\r
  19 Received: by yoom.home.cworth.org (Postfix, from userid 1000)\r
  20         id 595DB550090; Thu, 14 Jan 2010 14:24:55 -0800 (PST)\r
  21 From: Carl Worth <cworth@cworth.org>\r
  22 To: martin f krafft <madduck@madduck.net>\r
  23 In-Reply-To: <20100114080421.GA17305@lapse.rw.madduck.net>\r
  24 References: <20100111221909.GA30299@lapse.rw.madduck.net>\r
  25         <87hbqpfp47.fsf@yoom.home.cworth.org>\r
  26         <20100114080421.GA17305@lapse.rw.madduck.net>\r
  27 Date: Thu, 14 Jan 2010 14:24:54 -0800\r
  28 Message-ID: <87k4vke349.fsf@yoom.home.cworth.org>\r
  29 MIME-Version: 1.0\r
  30 Content-Type: multipart/signed; boundary="=-=-=";\r
  31         micalg=pgp-sha1; protocol="application/pgp-signature"\r
  32 Cc: notmuch discussion list <notmuch@notmuchmail.org>,\r
  33         mailtags discussion list <mailtags@lists.madduck.net>\r
  34 Subject: Re: [notmuch] Idea for storing tags\r
  35 X-BeenThere: notmuch@notmuchmail.org\r
  36 X-Mailman-Version: 2.1.13\r
  37 Precedence: list\r
  38 List-Id: "Use and development of the notmuch mail system."\r
  39         <notmuch.notmuchmail.org>\r
  40 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  41         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  42 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  43 List-Post: <mailto:notmuch@notmuchmail.org>\r
  44 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  45 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  46         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  47 X-List-Received-Date: Thu, 14 Jan 2010 22:24:56 -0000\r
  48 \r
  49 --=-=-=\r
  50 Content-Transfer-Encoding: quoted-printable\r
  51 \r
  52 On Thu, 14 Jan 2010 21:04:21 +1300, martin f krafft <madduck@madduck.net> w=\r
  53 rote:\r
  54 > You might have marked a message 'read' on one machine and if the two\r
  55 > get out of sync on another machine, you might have the same message\r
  56 > unread there.\r
  57 \r
  58 That's a different issue though. With two databases there's clearly the\r
  59 opportunity for the two databases to be out of synch.\r
  60 \r
  61 But you talked about the database being out of synch with respect to the\r
  62 mailstore. And that's something I just don't understand, (given the\r
  63 assumption that all tags are stored in the database---which was the\r
  64 explicit description of the case of interest).\r
  65 \r
  66 > Shouldn't this just be solved? I've had formail+procmail delete my\r
  67 > duplicates for 10+ years, and while I don't like the fact that\r
  68 > I usually get the CC before the list mail, and thus cannot filter on\r
  69 > Delivered-To, I have never looked back.\r
  70 \r
  71 Notmuch has access to all the information it needs to allow you to\r
  72 delete the CC version once the list mail arrives. So you could do\r
  73 notmuch-based deletion now and avoid losing the Delivered-To header if\r
  74 you want.\r
  75 \r
  76 > > [*] Though, I think a plain-text file with tags managed with\r
  77 > > something like git (and perhaps a custom merger) could save a lot\r
  78 > > of work. Or perhaps a plain-text journal of tag manipulations on\r
  79 > > either end that could be replayed on the other.\r
  80 >=20\r
  81 > Git is good at conflict resolution if run interactively, but [0]\r
  82 > still makes me question whether it can ever take the place of IMAP.\r
  83 > However, Asheesh Laroia, who has floated the idea of Git-for-mail at\r
  84 > DebConf8 already, has some ideas and hopefully will soon reply to my\r
  85 > mail [0], which I just bounced.\r
  86 >=20\r
  87 > 0. http://notmuchmail.org/pipermail/notmuch/2010/001114.html\r
  88 \r
  89 Using git for mail is an interesting idea, but not what I was actually\r
  90 proposing here.\r
  91 \r
  92 I think that synchronizing the mail store and synchronizing the tags\r
  93 information are tasks that have different requirements, and for which we\r
  94 may well want different tools.\r
  95 \r
  96 So I was talking about using imap (or rsync, or what have you) for\r
  97 copying the mailtstore, and then having something with a bit more\r
  98 domain-specific awareness for doing the synchronization of the tags\r
  99 data.\r
 100 \r
 101 =2DCarl\r
 102 \r
 103 --=-=-=\r
 104 Content-Type: application/pgp-signature\r
 105 \r
 106 -----BEGIN PGP SIGNATURE-----\r
 107 Version: GnuPG v1.4.10 (GNU/Linux)\r
 108 \r
 109 iD8DBQFLT5m36JDdNq8qSWgRAutDAJ9o/p21YhuWSITuN9pLdPOvx7Ic7wCgl/mc\r
 110 Pt/EwM8QlQzEHvYA90+iNus=\r
 111 =fS/3\r
 112 -----END PGP SIGNATURE-----\r
 113 --=-=-=--\r