--- /dev/null
+Return-Path: <amdragon@mit.edu>\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 EFBC0431FBF\r
+ for <notmuch@notmuchmail.org>; Wed, 23 Apr 2014 14:28:58 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -0.7\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5\r
+ tests=[RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled\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 VcMfwEmVbsEp for <notmuch@notmuchmail.org>;\r
+ Wed, 23 Apr 2014 14:28:51 -0700 (PDT)\r
+Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu\r
+ [18.9.25.15])\r
+ (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))\r
+ (No client certificate requested)\r
+ by olra.theworths.org (Postfix) with ESMTPS id 54BEA431FBD\r
+ for <notmuch@notmuchmail.org>; Wed, 23 Apr 2014 14:28:51 -0700 (PDT)\r
+X-AuditID: 1209190f-f790b6d000000c3a-5c-53583092726f\r
+Received: from mailhub-auth-1.mit.edu ( [18.9.21.35])\r
+ (using TLS with cipher AES256-SHA (256/256 bits))\r
+ (Client did not present a certificate)\r
+ by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP\r
+ id 7D.67.03130.29038535; Wed, 23 Apr 2014 17:28:50 -0400 (EDT)\r
+Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])\r
+ by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id s3NLSmnf002716; \r
+ Wed, 23 Apr 2014 17:28:49 -0400\r
+Received: from awakening.csail.mit.edu (awakening.csail.mit.edu [18.26.4.91])\r
+ (authenticated bits=0)\r
+ (User authenticated as amdragon@ATHENA.MIT.EDU)\r
+ by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s3NLSk48019621\r
+ (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT);\r
+ Wed, 23 Apr 2014 17:28:47 -0400\r
+Received: from amthrax by awakening.csail.mit.edu with local (Exim 4.80)\r
+ (envelope-from <amdragon@mit.edu>)\r
+ id 1Wd4ij-0004yg-2B; Wed, 23 Apr 2014 17:28:45 -0400\r
+Date: Wed, 23 Apr 2014 17:28:43 -0400\r
+From: Austin Clements <amdragon@MIT.EDU>\r
+To: David Mazieres expires 2014-07-05 CEST\r
+ <mazieres-2vu8n5xbqk4r8zkqh82n4qgci6@temporary-address.scs.stanford.edu>\r
+Subject: Re: [PATCH] Add configurable changed tag to messages that have been\r
+ changed on disk\r
+Message-ID: <20140423212843.GN25817@mit.edu>\r
+References: <1396800683-9164-1-git-send-email-eg@gaute.vetsj.com>\r
+ <87wqf2gqig.fsf@ta.scs.stanford.edu>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain; charset=us-ascii\r
+Content-Disposition: inline\r
+In-Reply-To: <87wqf2gqig.fsf@ta.scs.stanford.edu>\r
+User-Agent: Mutt/1.5.21 (2010-09-15)\r
+X-Brightmail-Tracker:\r
+ H4sIAAAAAAAAA+NgFuplleLIzCtJLcpLzFFi42IR4hRV1p1kEBFssOA1v0XT50usFqsWxVtc\r
+ vzmT2YHZ48e/ZjaPZ6tuMXtc+ruNKYA5issmJTUnsyy1SN8ugSvj57bTLAWzhSounj7K0sB4\r
+ hK+LkZNDQsBEYvLFD0wQtpjEhXvr2boYuTiEBGYzSdyctwbK2cgo0X96IjOEc5pJYtb1lawQ\r
+ zhJGicPnLoH1swioSky7t5gRxGYT0JDYtn85mC0iUCwx8fMFZhCbWcBGYsLH12wgtrBAnMS0\r
+ yzvAenkFdCSevl4AViMkkCFxYsYhFoi4oMTJmU9YIHq1JG78ewlUzwFkS0ss/8cBEuYUMJR4\r
+ tLqdFcQWFVCRmHJyG9sERqFZSLpnIemehdC9gJF5FaNsSm6Vbm5iZk5xarJucXJiXl5qka6J\r
+ Xm5miV5qSukmRnCoS/LvYPx2UOkQowAHoxIPr8Tl8GAh1sSy4srcQ4ySHExKorzJmhHBQnxJ\r
+ +SmVGYnFGfFFpTmpxYcYJTiYlUR4N2sD5XhTEiurUovyYVLSHCxK4rxvra2ChQTSE0tSs1NT\r
+ C1KLYLIyHBxKErxL9YEaBYtS01Mr0jJzShDSTBycIMN5gIbPB6nhLS5IzC3OTIfIn2JUlBLn\r
+ vagHlBAASWSU5sH1wlLRK0ZxoFeEeZtA2nmAaQyu+xXQYCagwQUTwkEGlyQipKQaGAXir9hG\r
+ mq/sWHJoN3vHPBMG4+NMZqKyNVtn7Pb3fdxQb2hbHXHgTeGR61L3hIr/XJk6W5nx+e7zL1nN\r
+ dt5cFXnfbVpfAqPp36g/6wriPmxhF/cw9jqjcii6crKwUbga+8pWHyPDFE2f5E8Rrdde/9h5\r
+ IPn+1dD9z14Zz+XQ6TlzlPXaGxG7v0osxRmJhlrMRcWJAFmmB+ggAwAA\r
+Cc: notmuch@notmuchmail.org\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: Wed, 23 Apr 2014 21:28:59 -0000\r
+\r
+Quoth David Mazieres on Apr 06 at 10:19 pm:\r
+> Gaute Hope <eg@gaute.vetsj.com> writes:\r
+> \r
+> > When one of the source files for a message is changed on disk, renamed,\r
+> > deleted or a new source file is added. A configurable changed tag is\r
+> > is added. The tag can be configured under the option 'changed_tags' in\r
+> > the [new] section, the default is none. Tests have been updated to\r
+> > accept the new config option.\r
+> >\r
+> > notmuch-setup now asks for a changed tag after the new tags question.\r
+> >\r
+> > This could be useful for for example 'afew' to detect remote changes in\r
+> > IMAP folders and update the FolderNameFilter to also add tags or remove\r
+> > tags when a _existing_ message has been added to or removed from a\r
+> > maildir.\r
+> \r
+> I think this is the wrong way to achieve such functionality, because\r
+> then the change tag A) is expensive to remove, B) is easy to misuse\r
+> (remember to call fsync everywhere before deleting the change tag), and\r
+> C) can be used by only one application.\r
+> \r
+> A better approach would be to add a new "modtime" xapian value that is\r
+> updated whenever the tags or any other terms (such as XFDIRENTRY) are\r
+> added to or deleted from a docid. If it's a Xapian value, rather than a\r
+> term, then modtime will be queriable just like date, allowing multiple\r
+> applications to query all docids modified since the last time they ran.\r
+\r
+I'd like to have efficient change detection, too. In my case, I'd\r
+like to use it to support efficient live search and show updates. The\r
+design I'd sketched out for that used a log rather than ctimes, and\r
+I'm curious if you have thoughts on the relative merits and\r
+suitability for tag sync of these approaches.\r
+\r
+I'd been leaning toward logging because it can capture changes to\r
+things that aren't represented as documents in the database, such as\r
+thread membership. This probably doesn't matter for synchronization,\r
+but it makes it much easier to figure out which threads in thread\r
+search results need to be refreshed. A log can also capture message\r
+deletion easily, while ctimes would require tombstones (which may be a\r
+good idea for other reasons [1]).\r
+\r
+On the other hand, logging is obviously more mechanism than ctimes,\r
+and probably requires some garbage collection story.\r
+\r
+[1] id:20140421162058.GE25817@mit.edu\r
projects / notmuch-archives.git / commitdiff