From acb290d1256f708c21fcc031aaef51e6a7dc76b0 Mon Sep 17 00:00:00 2001 From: David Mazieres Date: Mon, 28 Apr 2014 12:04:45 +1700 Subject: [PATCH] Re: github mirror --- 18/ff5eb2642433f8c8f6701c7f7666e26de0f43b | 98 +++++++++++++++++++++++ 1 file changed, 98 insertions(+) create mode 100644 18/ff5eb2642433f8c8f6701c7f7666e26de0f43b diff --git a/18/ff5eb2642433f8c8f6701c7f7666e26de0f43b b/18/ff5eb2642433f8c8f6701c7f7666e26de0f43b new file mode 100644 index 000000000..c7ccb459e --- /dev/null +++ b/18/ff5eb2642433f8c8f6701c7f7666e26de0f43b @@ -0,0 +1,98 @@ +Return-Path: + +X-Original-To: notmuch@notmuchmail.org +Delivered-To: notmuch@notmuchmail.org +Received: from localhost (localhost [127.0.0.1]) + by olra.theworths.org (Postfix) with ESMTP id 91A10431FBC + for ; Sun, 27 Apr 2014 12:04:55 -0700 (PDT) +X-Virus-Scanned: Debian amavisd-new at olra.theworths.org +X-Spam-Flag: NO +X-Spam-Score: -2.3 +X-Spam-Level: +X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 + tests=[RCVD_IN_DNSWL_MED=-2.3] autolearn=disabled +Received: from olra.theworths.org ([127.0.0.1]) + by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id Nnq-5Rh-gp1q for ; + Sun, 27 Apr 2014 12:04:50 -0700 (PDT) +Received: from market.scs.stanford.edu (market.scs.stanford.edu [171.66.3.10]) + (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) + (No client certificate requested) + by olra.theworths.org (Postfix) with ESMTPS id B3F84431FBD + for ; Sun, 27 Apr 2014 12:04:50 -0700 (PDT) +Received: from market.scs.stanford.edu (localhost.scs.stanford.edu + [127.0.0.1]) by market.scs.stanford.edu (8.14.7/8.14.7) with ESMTP id + s3RJ4mdN004982; Sun, 27 Apr 2014 12:04:48 -0700 (PDT) +Received: (from dm@localhost) + by market.scs.stanford.edu (8.14.7/8.14.7/Submit) id s3RJ4mBW004370; + Sun, 27 Apr 2014 12:04:48 -0700 (PDT) +X-Authentication-Warning: market.scs.stanford.edu: dm set sender to + return-bir96xbtgutgpvufrj76wjfa92@ta.scs.stanford.edu using -f +From: David Mazieres +To: Sam Halliday , notmuch@notmuchmail.org +Subject: Re: github mirror +In-Reply-To: <87bnvn111h.fsf@Samskara.home> +References: <87bnvn111h.fsf@Samskara.home> +Date: Sun, 27 Apr 2014 12:04:45 -0700 +Message-ID: <87iopu4mr6.fsf@ta.scs.stanford.edu> +MIME-Version: 1.0 +Content-Type: text/plain +X-BeenThere: notmuch@notmuchmail.org +X-Mailman-Version: 2.1.13 +Precedence: list +Reply-To: David Mazieres expires 2014-07-26 PDT + +List-Id: "Use and development of the notmuch mail system." + +List-Unsubscribe: , + +List-Archive: +List-Post: +List-Help: +List-Subscribe: , + +X-List-Received-Date: Sun, 27 Apr 2014 19:04:55 -0000 + +Sam Halliday writes: + +> Dear NotMuch, +> +> But in any case, my RFE/question was this: how hard would it be to have +> an optional mode of behaviour where tags are stored in the message +> itself, so that syncing with an IMAP server (e.g. via offlineimap) +> would make the tags available on all devices. This would negate the need +> for workarounds, such as shared notmuch databases, when users have +> multiple machines. + +The problem is that different imap servers store tags in different +ways. Since notmuch does not use imap, it would be hard for notmuch to +synchronize the tags, other than the standard ones (for which notmuch +already has support). + +One thing you could do is build an external tool that synchronizes +notmuch tags and spawns an imap server in preauth mode to sync the tags. +(That would be yet another use for the ctime values we have discussed on +this list.) + +> It would also allow applications like offlineimap to introduce a gmail +> plugin that would copy the message into a folder according to its tags, +> so gmail labels and notmuch tags would be in sync. + +Unfortunately, offlineimap is dog slow, especially when you have a ton +of maildirs. It just doesn't seem to pipeline very well at all. Even +when I run 5 or 10 threads, it still seems to take a whole bunch of +round trip times. + +I used to want what you want. But then it got to the point that +offlineimap was taking 30 seconds to sync my 60 maildirs over 3G, even +when there was no new mail. Worse, one thread seems to busy-wait for +the others to finish, so it often pegs the CPU and drains the battery on +my laptop. + +As a result, I built a tool that synchronizes notmuch tags directly. +Now my problem is waiting for "notmuch new" to run, but at least the +synchronization part is really fast and pleasant. I'll be releasing my +tool in the next couple of months once I've kicked the tires a bit more +and fixed up a few things. + +David -- 2.26.2