Re: [PATCH v4 0/4] Maildir synchronization

diff --git a/39/59943ca821b1228e6ffdae631410ce9a877401 b/39/59943ca821b1228e6ffdae631410ce9a877401
new file mode 100644 (file)
index 0000000..1e55020
--- /dev/null
+++ b/39/59943ca821b1228e6ffdae631410ce9a877401
@@ -0,0 +1,136 @@
+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 62EE740DAF4\r
+       for <notmuch@notmuchmail.org>; Mon,  8 Nov 2010 14:03:34 -0800 (PST)\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 5KqKjTiaMAT3; Mon,  8 Nov 2010 14:03:22 -0800 (PST)\r
+Received: from yoom.home.cworth.org (localhost [127.0.0.1])\r
+       by olra.theworths.org (Postfix) with ESMTP id F33D140DACC;\r
+       Mon,  8 Nov 2010 14:03:21 -0800 (PST)\r
+Received: by yoom.home.cworth.org (Postfix, from userid 1000)\r
+       id A347225412C; Mon,  8 Nov 2010 11:35:18 -0800 (PST)\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: <87d3qhq527.fsf@resox.2x.cz>\r
+References: <87tyk3vpxd.fsf@wsheee.2x.cz>\r
+       <1288560558-18915-1-git-send-email-sojkam1@fel.cvut.cz>\r
+       <877hgsrjau.fsf@yoom.home.cworth.org> <87d3qhq527.fsf@resox.2x.cz>\r
+User-Agent: Notmuch/0.4 (http://notmuchmail.org) Emacs/23.2.1\r
+       (i486-pc-linux-gnu)\r
+Date: Mon, 08 Nov 2010 11:35:18 -0800\r
+Message-ID: <874obrmww9.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: Mon, 08 Nov 2010 22:03:34 -0000\r
+\r
+--=-=-=\r
+Content-Transfer-Encoding: quoted-printable\r
+\r
+On Sun, 07 Nov 2010 02:46:08 +0100, Michal Sojka <sojkam1@fel.cvut.cz> wrot=\r
+e:\r
+> On Thu, 04 Nov 2010, Carl Worth wrote:\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
+>=20\r
+> I can imagine two other solutions. One would be to add a parameter\r
+> (probably called flags) to the following functions:\r
+>=20\r
+>     notmuch_message_add_tag()\r
+>     notmuch_message_remove_tag()\r
+>     notmuch_message_thaw()\r
+...\r
+> The other option would be to put a flag into notmuch_message_t but this\r
+> is probably not very different from having it in notmuch_database_t.\r
+\r
+Here's yet another approach that I have in mind.\r
+\r
+We can implement all of the support by adding two new library functions:\r
+\r
+       notmuch_database_add_message_with_maildir_flags\r
+       notmuch_message_sync_with_maildir_flags\r
+\r
+These functions would work like the existing\r
+notmuch_database_add_message and notmuch_message_sync except they would\r
+do the maildir-flag synchronization.\r
+\r
+This allows a user of the library to do whatever it wants, (no\r
+synchronization, one-way synchronization in either direction, or two-way\r
+synchronization), without having any sort of "configuration" API calls\r
+in the library.\r
+\r
+> I think I could make notmuch_message_maildir_to_flags() private and call\r
+> it from notmuch_database_add_message() so that both directions will be\r
+> implemented in the library.\r
+\r
+Yes. That's in line with what I propose above.\r
+\r
+> The current implementation renames only the file whose name is stored\r
+> first in the database. I have a TODO comment there to add a loop through\r
+> all file names, but I have never realized that deleted flag could be so\r
+> dangerous.\r
+\r
+I think what I'd like to do for now is to simply remove "deleted" from\r
+the set of tags being manipulated by this support. This is the similar\r
+to what Sebastian decided to do with notmuchsync when he described in\r
+detail the same scenario I was concerned with:\r
+\r
+       id:87eickhor1.fsf@SSpaeth.de\r
+\r
+Sebastian's solution was slightly different, ("deleted" was not\r
+synchronized by default but could be explicitly requested). I propose\r
+simply not synchronizing "deleted" until it can be made safe.\r
+\r
+> It will take me probably a few days until I find time to work on this.\r
+> So let me now in that time whether you have some preferences in the\r
+> above.\r
+\r
+I'd like to get things merged today, so I plan to take your patches and\r
+then add new commits on top to implement the functions I described\r
+above.\r
+\r
+I'll be interested in any feedback.\r
+\r
+Thanks again,\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
+iD8DBQFM2FD26JDdNq8qSWgRAqFpAJ9yhb5LuyC/LX+FCrb4dcY4bxOvxgCfRVzk\r
+gmDXmtJz30XWY2aHp/WkOhs=\r
+=f45/\r
+-----END PGP SIGNATURE-----\r
+--=-=-=--\r