Re: [PATCH v4 0/4] Maildir synchronization

diff --git a/1c/be16e33fe60d64572805406e2a4392541adea5 b/1c/be16e33fe60d64572805406e2a4392541adea5
new file mode 100644 (file)
index 0000000..2804148
--- /dev/null
+++ b/1c/be16e33fe60d64572805406e2a4392541adea5
@@ -0,0 +1,145 @@
+Return-Path: <cworth@cworth.org>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+       by olra.theworths.org (Postfix) with ESMTP id 46CC440D156\r
+       for <notmuch@notmuchmail.org>; Thu,  4 Nov 2010 12:16:36 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -2.89\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-2.89 tagged_above=-999 required=5\r
+       tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, T_MIME_NO_TEXT=0.01]\r
+       autolearn=ham\r
+Received: from olra.theworths.org ([127.0.0.1])\r
+       by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
+       with ESMTP id 9IN3J-k1lp4x; Thu,  4 Nov 2010 12:16:26 -0700 (PDT)\r
+Received: from yoom.home.cworth.org (localhost [127.0.0.1])\r
+       by olra.theworths.org (Postfix) with ESMTP id D942E40D152;\r
+       Thu,  4 Nov 2010 12:16:25 -0700 (PDT)\r
+Received: by yoom.home.cworth.org (Postfix, from userid 1000)\r
+       id 88CF3254102; Thu,  4 Nov 2010 12:16:25 -0700 (PDT)\r
+From: Carl Worth <cworth@cworth.org>\r
+To: Michal Sojka <sojkam1@fel.cvut.cz>, notmuch@notmuchmail.org\r
+Subject: Re: [PATCH v4 0/4] Maildir synchronization\r
+In-Reply-To: <1288560558-18915-1-git-send-email-sojkam1@fel.cvut.cz>\r
+References: <87tyk3vpxd.fsf@wsheee.2x.cz>\r
+       <1288560558-18915-1-git-send-email-sojkam1@fel.cvut.cz>\r
+User-Agent: Notmuch/0.4 (http://notmuchmail.org) Emacs/23.2.1\r
+       (i486-pc-linux-gnu)\r
+Date: Thu, 04 Nov 2010 12:16:25 -0700\r
+Message-ID: <877hgsrjau.fsf@yoom.home.cworth.org>\r
+MIME-Version: 1.0\r
+Content-Type: multipart/signed; boundary="=-=-=";\r
+       micalg=pgp-sha1; protocol="application/pgp-signature"\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+       <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
+       <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+       <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Thu, 04 Nov 2010 19:16:36 -0000\r
+\r
+--=-=-=\r
+Content-Transfer-Encoding: quoted-printable\r
+\r
+On Sun, 31 Oct 2010 22:29:14 +0100, Michal Sojka <sojkam1@fel.cvut.cz> wrot=\r
+e:\r
+> This is the next iteration of maildir synchronization patches. The\r
+> changes are:\r
+> - Configuration is now simplified. The synchronization can only be\r
+>   full enabled or disabled. By default it is still disabled.\r
+> - Added test for notmuch restore (with enabled synchronization)\r
+> - Rebased to the current master\r
+> - 'D' flag is mapped to 'deleted' tag instead of 'delete' (this has\r
+>   already been in v3)\r
+\r
+This is coming along nicely, Michal. I'm delighted to see the testing\r
+here and the improved configuration support.\r
+\r
+I think after merging this, I'd be inclined to change two tiny things:\r
+\r
+       1. Enable it by default\r
+\r
+       2. Augment the documentation in the configuration file to say\r
+          exactly which tags are synchronized with which flags.\r
+\r
+I could easily do those in follow-up commits, so there's no need to\r
+worry about resending the series for those.\r
+\r
+Meanwhile, here are some of the things I'm still thinking about in\r
+regards to this patch. First, the commit message describes the\r
+synchronization happening at "notmuch new" and "notmuch tag/notmuch\r
+restore". But the implementation shows that the functionality is within\r
+the library, not the command-line tool above it.\r
+\r
+I think having this at the library makes sense, but as you certainly\r
+noticed, the library has historically been entirely unaware of any\r
+configuration, (which I'd like to keep). Obviously, you maintained that\r
+separation in your patch series, but you added a new\r
+notmuch_database_set_maildir_sync function so that the library can be\r
+informed of the desired behavior.\r
+\r
+I'm not entirely sure I like a big, global state-changing function like\r
+that in the library. But if we do want to have that, we need to fix the\r
+documentation of all functions that are affected by it to correctly\r
+document their current behavior.\r
+\r
+Also, the synchronization is inherently 2-way, but the two directions\r
+are implemented differently in the library. One direction, (from tags to\r
+maildir flags), is implemented implicitly in the library (existing\r
+functions do the new synchronization under the influence of\r
+database_set_maildir_sync). But the other direction, (from maildir flags\r
+to tags), requires an explicit call to a new function\r
+(notmuch_message_maildir_to_flags). I definitely don't like this.\r
+\r
+Finally, the documentation for notmuch_message_maildir_to_tags ("Add or\r
+remove tags based on the maildir flags in the file name")\r
+inadequate. This documentation needs to say which tags are added/removed\r
+in what conditions. It should also give guidance on when this function\r
+should be called in order to achieve some particular behavior.\r
+\r
+I recognize that in the above I don't give specific guidance on whether\r
+the new functionality should be implicit or explicit in the\r
+library. I'm not certain which is better, and I'm willing to listen to\r
+justification from someone who has spent some time implementing and\r
+testing this stuff. But I don't like the current mixed state.\r
+\r
+One other issue, how does this support deal with multiple files that\r
+have the same message ID (and hence a single record in the database)?\r
+Some bad failure modes I can imagine are cycling of tags/filenames with\r
+successive runs of notmuch new, or "leaking"[*] of tags from one filename\r
+to another through the database.\r
+\r
+[*] Imagine, for example, someone using an external client that\r
+identifies duplicate messages in the mailstore and adds the maildir flag\r
+corresponding to "deleted" to all but one of each of the\r
+duplicates. There's then the possibility that notmuch could propagate\r
+this "deleted" flag through the "deleted" tag in the database, (perhaps\r
+after a notmuch dump/restore cycle). And that could be a catastrophic\r
+result if all messages that have duplicates get flagged for deletion!\r
+\r
+What thoughts do you have on this multiple-file issue?\r
+\r
+=2DCarl\r
+\r
+=2D-=20\r
+carl.d.worth@intel.com\r
+\r
+--=-=-=\r
+Content-Type: application/pgp-signature\r
+\r
+-----BEGIN PGP SIGNATURE-----\r
+Version: GnuPG v1.4.10 (GNU/Linux)\r
+\r
+iD8DBQFM0waJ6JDdNq8qSWgRAk6XAKCn70p+NWXp1vi/cJZisS0fUUmHEgCgqoEw\r
+352iR5Y5KX9vlbjlNV2VW1M=\r
+=36xL\r
+-----END PGP SIGNATURE-----\r
+--=-=-=--\r