1c/be16e33fe60d64572805406e2a4392541adea5

   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 46CC440D156\r
   6         for <notmuch@notmuchmail.org>; Thu,  4 Nov 2010 12:16:36 -0700 (PDT)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: -2.89\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-2.89 tagged_above=-999 required=5\r
  12         tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, T_MIME_NO_TEXT=0.01]\r
  13         autolearn=ham\r
  14 Received: from olra.theworths.org ([127.0.0.1])\r
  15         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  16         with ESMTP id 9IN3J-k1lp4x; Thu,  4 Nov 2010 12:16:26 -0700 (PDT)\r
  17 Received: from yoom.home.cworth.org (localhost [127.0.0.1])\r
  18         by olra.theworths.org (Postfix) with ESMTP id D942E40D152;\r
  19         Thu,  4 Nov 2010 12:16:25 -0700 (PDT)\r
  20 Received: by yoom.home.cworth.org (Postfix, from userid 1000)\r
  21         id 88CF3254102; Thu,  4 Nov 2010 12:16:25 -0700 (PDT)\r
  22 From: Carl Worth <cworth@cworth.org>\r
  23 To: Michal Sojka <sojkam1@fel.cvut.cz>, notmuch@notmuchmail.org\r
  24 Subject: Re: [PATCH v4 0/4] Maildir synchronization\r
  25 In-Reply-To: <1288560558-18915-1-git-send-email-sojkam1@fel.cvut.cz>\r
  26 References: <87tyk3vpxd.fsf@wsheee.2x.cz>\r
  27         <1288560558-18915-1-git-send-email-sojkam1@fel.cvut.cz>\r
  28 User-Agent: Notmuch/0.4 (http://notmuchmail.org) Emacs/23.2.1\r
  29         (i486-pc-linux-gnu)\r
  30 Date: Thu, 04 Nov 2010 12:16:25 -0700\r
  31 Message-ID: <877hgsrjau.fsf@yoom.home.cworth.org>\r
  32 MIME-Version: 1.0\r
  33 Content-Type: multipart/signed; boundary="=-=-=";\r
  34         micalg=pgp-sha1; protocol="application/pgp-signature"\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, 04 Nov 2010 19:16:36 -0000\r
  48 \r
  49 --=-=-=\r
  50 Content-Transfer-Encoding: quoted-printable\r
  51 \r
  52 On Sun, 31 Oct 2010 22:29:14 +0100, Michal Sojka <sojkam1@fel.cvut.cz> wrot=\r
  53 e:\r
  54 > This is the next iteration of maildir synchronization patches. The\r
  55 > changes are:\r
  56 > - Configuration is now simplified. The synchronization can only be\r
  57 >   full enabled or disabled. By default it is still disabled.\r
  58 > - Added test for notmuch restore (with enabled synchronization)\r
  59 > - Rebased to the current master\r
  60 > - 'D' flag is mapped to 'deleted' tag instead of 'delete' (this has\r
  61 >   already been in v3)\r
  62 \r
  63 This is coming along nicely, Michal. I'm delighted to see the testing\r
  64 here and the improved configuration support.\r
  65 \r
  66 I think after merging this, I'd be inclined to change two tiny things:\r
  67 \r
  68         1. Enable it by default\r
  69 \r
  70         2. Augment the documentation in the configuration file to say\r
  71            exactly which tags are synchronized with which flags.\r
  72 \r
  73 I could easily do those in follow-up commits, so there's no need to\r
  74 worry about resending the series for those.\r
  75 \r
  76 Meanwhile, here are some of the things I'm still thinking about in\r
  77 regards to this patch. First, the commit message describes the\r
  78 synchronization happening at "notmuch new" and "notmuch tag/notmuch\r
  79 restore". But the implementation shows that the functionality is within\r
  80 the library, not the command-line tool above it.\r
  81 \r
  82 I think having this at the library makes sense, but as you certainly\r
  83 noticed, the library has historically been entirely unaware of any\r
  84 configuration, (which I'd like to keep). Obviously, you maintained that\r
  85 separation in your patch series, but you added a new\r
  86 notmuch_database_set_maildir_sync function so that the library can be\r
  87 informed of the desired behavior.\r
  88 \r
  89 I'm not entirely sure I like a big, global state-changing function like\r
  90 that in the library. But if we do want to have that, we need to fix the\r
  91 documentation of all functions that are affected by it to correctly\r
  92 document their current behavior.\r
  93 \r
  94 Also, the synchronization is inherently 2-way, but the two directions\r
  95 are implemented differently in the library. One direction, (from tags to\r
  96 maildir flags), is implemented implicitly in the library (existing\r
  97 functions do the new synchronization under the influence of\r
  98 database_set_maildir_sync). But the other direction, (from maildir flags\r
  99 to tags), requires an explicit call to a new function\r
 100 (notmuch_message_maildir_to_flags). I definitely don't like this.\r
 101 \r
 102 Finally, the documentation for notmuch_message_maildir_to_tags ("Add or\r
 103 remove tags based on the maildir flags in the file name")\r
 104 inadequate. This documentation needs to say which tags are added/removed\r
 105 in what conditions. It should also give guidance on when this function\r
 106 should be called in order to achieve some particular behavior.\r
 107 \r
 108 I recognize that in the above I don't give specific guidance on whether\r
 109 the new functionality should be implicit or explicit in the\r
 110 library. I'm not certain which is better, and I'm willing to listen to\r
 111 justification from someone who has spent some time implementing and\r
 112 testing this stuff. But I don't like the current mixed state.\r
 113 \r
 114 One other issue, how does this support deal with multiple files that\r
 115 have the same message ID (and hence a single record in the database)?\r
 116 Some bad failure modes I can imagine are cycling of tags/filenames with\r
 117 successive runs of notmuch new, or "leaking"[*] of tags from one filename\r
 118 to another through the database.\r
 119 \r
 120 [*] Imagine, for example, someone using an external client that\r
 121 identifies duplicate messages in the mailstore and adds the maildir flag\r
 122 corresponding to "deleted" to all but one of each of the\r
 123 duplicates. There's then the possibility that notmuch could propagate\r
 124 this "deleted" flag through the "deleted" tag in the database, (perhaps\r
 125 after a notmuch dump/restore cycle). And that could be a catastrophic\r
 126 result if all messages that have duplicates get flagged for deletion!\r
 127 \r
 128 What thoughts do you have on this multiple-file issue?\r
 129 \r
 130 =2DCarl\r
 131 \r
 132 =2D-=20\r
 133 carl.d.worth@intel.com\r
 134 \r
 135 --=-=-=\r
 136 Content-Type: application/pgp-signature\r
 137 \r
 138 -----BEGIN PGP SIGNATURE-----\r
 139 Version: GnuPG v1.4.10 (GNU/Linux)\r
 140 \r
 141 iD8DBQFM0waJ6JDdNq8qSWgRAk6XAKCn70p+NWXp1vi/cJZisS0fUUmHEgCgqoEw\r
 142 352iR5Y5KX9vlbjlNV2VW1M=\r
 143 =36xL\r
 144 -----END PGP SIGNATURE-----\r
 145 --=-=-=--\r