42/daa364532bf0cccc783a7bb70287df973e1852

   1 Return-Path: <bgamari@gmail.com>\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 C42AA431FC3\r
   6         for <notmuch@notmuchmail.org>; Mon,  1 Mar 2010 10:43:37 -0800 (PST)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: -0.992\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-0.992 tagged_above=-999 required=5\r
  12         tests=[AWL=-0.807, BAYES_40=-0.185] autolearn=ham\r
  13 Received: from olra.theworths.org ([127.0.0.1])\r
  14         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  15         with ESMTP id owhqKfkkMH+y for <notmuch@notmuchmail.org>;\r
  16         Mon,  1 Mar 2010 10:43:37 -0800 (PST)\r
  17 Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152])\r
  18         by olra.theworths.org (Postfix) with ESMTP id D6F38431FBD\r
  19         for <notmuch@notmuchmail.org>; Mon,  1 Mar 2010 10:43:36 -0800 (PST)\r
  20 Received: by fg-out-1718.google.com with SMTP id e21so52424fga.2\r
  21         for <notmuch@notmuchmail.org>; Mon, 01 Mar 2010 10:43:28 -0800 (PST)\r
  22 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;\r
  23         h=domainkey-signature:received:received:content-type:cc:subject:from\r
  24         :to:in-reply-to:references:date:message-id:user-agent\r
  25         :content-transfer-encoding;\r
  26         bh=FpPW3fXAdcu5Uza5ZSsSviAWiD3XN55Q5pBvJe59f1o=;\r
  27         b=qCw7AFPVO762soCv3HNxcFCtOK7OKJaD1EB5hGNclpamm4Ixfvsxg5JUrhiMPRPcBJ\r
  28         bbl066vBCRoxM6WXVHAiyXxpd+Yv3v/q9IEwrAbwoPC74XD1P9Fi2/2esRPJgVieo9hi\r
  29         2FTrbrAbQMo0rV4/+JRdcsQCEhpyVAaUxEgss=\r
  30 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;\r
  31         h=content-type:cc:subject:from:to:in-reply-to:references:date\r
  32         :message-id:user-agent:content-transfer-encoding;\r
  33         b=a53iGfYOkRYe+OJP9dEKXnUwEomgPrFyPrrIGKNkguOR36/yfx9jhysaFMSgzJpMet\r
  34         l1gh29YPfD2GkMJz+z/ZIojX1haVrrD/stITVbZlBQi9vgOsYW877hB9AmzxlHCCM6ay\r
  35         RlToDIPnIoK9I8LMO5/wSA3tFRa3qKV0hBLok=\r
  36 Received: by 10.87.38.5 with SMTP id q5mr7974813fgj.45.1267469007567;\r
  37         Mon, 01 Mar 2010 10:43:27 -0800 (PST)\r
  38 Received: from localhost (physnat56.physics.umass.edu [128.119.50.56])\r
  39         by mx.google.com with ESMTPS id 15sm2347572fxm.12.2010.03.01.10.43.26\r
  40         (version=TLSv1/SSLv3 cipher=RC4-MD5);\r
  41         Mon, 01 Mar 2010 10:43:26 -0800 (PST)\r
  42 Content-Type: text/plain; charset=UTF-8\r
  43 From: Ben Gamari <bgamari@gmail.com>\r
  44 To: Michal Sojka <sojkam1@fel.cvut.cz>\r
  45 In-reply-to: <87bpf82c5c.fsf@steelpick.localdomain>\r
  46 References: <87pr57jvkz.fsf@SSpaeth.de> <87wry2wl7p.fsf@yoom.home.cworth.org>\r
  47         <87ljecmnbd.fsf@steelpick.localdomain>\r
  48         <1267459947-sup-6640@ben-laptop>\r
  49         <87bpf82c5c.fsf@steelpick.localdomain>\r
  50 Date: Mon, 01 Mar 2010 13:43:24 -0500\r
  51 Message-Id: <1267468550-sup-8956@ben-laptop>\r
  52 User-Agent: Sup/git\r
  53 Content-Transfer-Encoding: 8bit\r
  54 Cc: notmuch <notmuch@notmuchmail.org>\r
  55 Subject: Re: [notmuch] Introducing notmuchsync\r
  56 X-BeenThere: notmuch@notmuchmail.org\r
  57 X-Mailman-Version: 2.1.13\r
  58 Precedence: list\r
  59 List-Id: "Use and development of the notmuch mail system."\r
  60         <notmuch.notmuchmail.org>\r
  61 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  62         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  63 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  64 List-Post: <mailto:notmuch@notmuchmail.org>\r
  65 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  66 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  67         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  68 X-List-Received-Date: Mon, 01 Mar 2010 18:43:37 -0000\r
  69 \r
  70 Excerpts from Michal Sojka's message of Mon Mar 01 12:18:55 -0500 2010:\r
  71 > > Is this really necessary? Another option (which I believe has been\r
  72 > > mentioned here in the past) is to simply pass notmuch new a list of\r
  73 > > message "paths" to add (although I'm not sure if many mail delivery\r
  74 > > programs give you that sort of information). \r
  75 > \r
  76 > This could also be possible, but now, you say "notmuch new" and notmuch\r
  77 > itself figure out what to index. If passing notmuch a list on files to\r
  78 > index will be the only supported way, it might be hard for new users to\r
  79 > start with notmuch. A nice thing on notmuch is that it can be used\r
  80 > almost without any configuration.\r
  81 \r
  82 It seems like a script in contrib/ would suffice.\r
  83 \r
  84 > \r
  85 > > How do you propose that the backends keep track of what mail has been\r
  86 > > indexed?\r
  87 > \r
  88 > For example by using Xapian metadata:\r
  89 > notmuch->xapian_db->set_metadata ("git-head", sha1);\r
  90 \r
  91 However, this means that the backend would need to know about the\r
  92 indexing database, which seems to me like a implementation detail that\r
  93 should be hidden from the backend (perhaps? Maybe not, I suppose). I guess this all\r
  94 depends upon how much we want to abstract out the backends.\r
  95 \r
  96 > \r
  97 > > > Now, if we have this, it would be very easy to add support for\r
  98 > > > Maildir-based mail-store. The implementation of the first two methods\r
  99 > > > would be the same as what is currently in notmuch and the third method\r
 100 > > > would rename files in mailstore if certain tags (such as unread) are\r
 101 > > > added or removed. In case of rename, notmuch database would be\r
 102 > > > immediately updated to reflect the change.\r
 103 > > > \r
 104 > > The interface here seems a little vague. How would the backend notify\r
 105 > > notmuch that the filename has changed?\r
 106 > \r
 107 > notmuch new\r
 108 > \r
 109 > The idea is that tags changed by notmuch are stored immediately (and\r
 110 > database is updated accordingly), whereas when the mail store is changed\r
 111 > by an external tool, you must explicitly ask notmuch to notice that.\r
 112 > \r
 113 Certainly, I understand that and believe that that is the only sane\r
 114 approach. However, you currently have no mechanism in your interface to\r
 115 allow the backend to notify notmuch that the file name has changed.\r
 116 Considering this is the sole value identifying the message to notmuch,\r
 117 you definitely need to tell notmuch about the change.\r
 118 \r
 119 > > Don't forget mbox. It seems like it would be pretty trivial to\r
 120 > > implement (although I'm not sure what performance would look like).\r
 121 > \r
 122 > I personally do not use mboxes, so I'm not interested in them.\r
 123 \r
 124 Fair enough. Just figured it wouldn't be too difficult (although I know\r
 125 very little about the format).\r
 126 \r
 127 > > With all of this infrastructure, it seems like it wouldn't be too\r
 128 > > difficult to support messages from multiple backends in a single index.\r
 129 > > Not sure if people would be interested enough to warrant the added\r
 130 > > complexity though.\r
 131 > \r
 132 > I'm currently not interested in such a functionality, but we can add it\r
 133 > later if there is a need.\r
 134 \r
 135 Certainly. Just throwing out ideas. \r
 136 \r
 137 - Ben\r