0a/e96348e01e3286f6d2853ba90f6bceddcfde51

   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 1ADED431FDA\r
   6         for <notmuch@notmuchmail.org>; Thu, 28 Jan 2010 15:30:27 -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.866\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-0.866 tagged_above=-999 required=5\r
  12         tests=[AWL=-0.867, BAYES_50=0.001] 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 vscTmJD9Ifqt for <notmuch@notmuchmail.org>;\r
  16         Thu, 28 Jan 2010 15:30:26 -0800 (PST)\r
  17 Received: from mail-yx0-f200.google.com (mail-yx0-f200.google.com\r
  18         [209.85.210.200])\r
  19         by olra.theworths.org (Postfix) with ESMTP id 22F1E431FD5\r
  20         for <notmuch@notmuchmail.org>; Thu, 28 Jan 2010 15:30:26 -0800 (PST)\r
  21 Received: by yxe38 with SMTP id 38so1254886yxe.6\r
  22         for <notmuch@notmuchmail.org>; Thu, 28 Jan 2010 15:30:20 -0800 (PST)\r
  23 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;\r
  24         h=domainkey-signature:received:received:content-type:subject:from:to\r
  25         :in-reply-to:references:date:message-id:user-agent\r
  26         :content-transfer-encoding;\r
  27         bh=A+pqBrMHNGZP1qwrF3AiyMp8/0i8OC0agF14SK0evws=;\r
  28         b=WhJg3FGBtaABDH6BAWYT8aSyvQtlcwwcV7F79XXM4QEUwWnwjrJWUI/pE+4EHeeNz9\r
  29         eLkUfuA1ElGjbZdc2fU5lJ9GVuhHeo7uHUhRYx4en5yN37CYYaWwRYAVMGwyKmYSF+nW\r
  30         6k63hL6kaTopH000asslyX1zqaOMH4XHteRdQ=\r
  31 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;\r
  32         h=content-type:subject:from:to:in-reply-to:references:date:message-id\r
  33         :user-agent:content-transfer-encoding;\r
  34         b=L16sdvkwgRW8dUatELTIzKk+PFhNUOs09fvf1/aHzL8q4eSKrkDI2FxH5jz7/L9M84\r
  35         Z8dy58EAEBeXVE5FqSSc0WTp7j/CiiqMDID1ZW/AsDg2jO3MiGyZ8UxN9i1gkau3xeVS\r
  36         RkkO9/XoBz643/UzGcE0evG/giCCai7h2t0Js=\r
  37 Received: by 10.150.55.17 with SMTP id d17mr637080yba.155.1264721419428;\r
  38         Thu, 28 Jan 2010 15:30:19 -0800 (PST)\r
  39 Received: from localhost (umass-959-98.wireless.umass.edu [128.119.77.98])\r
  40         by mx.google.com with ESMTPS id 7sm501333yxg.14.2010.01.28.15.30.17\r
  41         (version=TLSv1/SSLv3 cipher=RC4-MD5);\r
  42         Thu, 28 Jan 2010 15:30:18 -0800 (PST)\r
  43 Content-Type: text/plain; charset=UTF-8\r
  44 From: Ben Gamari <bgamari@gmail.com>\r
  45 To: martin f krafft <madduck@madduck.net>, notmuch <notmuch@notmuchmail.org>\r
  46 In-reply-to: <20100128221735.GE8942@lapse.rw.madduck.net>\r
  47 References: <20100125162247.85F0F66FA8@aether.pioto.org>\r
  48         <87tyu9dfhs.fsf@servo.finestructure.net>\r
  49         <20100128051057.GA12540@lapse.rw.madduck.net>\r
  50         <b22065d01001280432k55b627c1hb6405985f022e9cf@mail.gmail.com>\r
  51         <20100128203910.GC5237@lapse.rw.madduck.net>\r
  52         <1264711745-sup-8326@ben-laptop>\r
  53         <20100128211120.GA8942@lapse.rw.madduck.net>\r
  54         <1264713802-sup-620@ben-laptop>\r
  55         <20100128221735.GE8942@lapse.rw.madduck.net>\r
  56 Date: Thu, 28 Jan 2010 18:30:16 -0500\r
  57 Message-Id: <1264719647-sup-9540@ben-laptop>\r
  58 User-Agent: Sup/git\r
  59 Content-Transfer-Encoding: 8bit\r
  60 Subject: Re: [notmuch] tag dir proposal [was: Re: Git as notmuch object\r
  61         store]\r
  62 X-BeenThere: notmuch@notmuchmail.org\r
  63 X-Mailman-Version: 2.1.13\r
  64 Precedence: list\r
  65 List-Id: "Use and development of the notmuch mail system."\r
  66         <notmuch.notmuchmail.org>\r
  67 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  68         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  69 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  70 List-Post: <mailto:notmuch@notmuchmail.org>\r
  71 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  72 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  73         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  74 X-List-Received-Date: Thu, 28 Jan 2010 23:30:27 -0000\r
  75 \r
  76 Excerpts from martin f krafft's message of Thu Jan 28 17:17:35 -0500 2010:\r
  77 > Cron-scheduling is a regular activity. I am talking about\r
  78 > event-based scheduling. incron could do that and fire up a process\r
  79 > every time a message is dropped into a directory, but notmuch\r
  80 > doesn't provide me with an interface to say "you don't have to\r
  81 > iterate the Maildir yourself since I know exactly what changed: just\r
  82 > update your catalog with the new message in file foo/bar.msg".\r
  83 \r
  84 Fair enough. After reading your arguments I think I might have initially\r
  85 misunderstood you. I would actually tend to agree. Passing\r
  86 paths to notmuch does seem to be a reasonable approach.\r
  87 \r
  88 > \r
  89 > To me, notmuch-new is not Unix-y. To me,\r
  90 > \r
  91 >   find $MAILDIR -type f -print0 | xargs -0 notmuch-update\r
  92 > \r
  93 > is Unix-y. ;)\r
  94 > \r
  95 I think it really depends upon what you are doing. I can certainly see\r
  96 when you might be want to simply have notmuch synchronize the index\r
  97 against the mail store. However, it seems the majority of the time one\r
  98 simply desires to add a message to the index (i.e. after delivery).\r
  99 Therefore, it seems like there is a place for both commands.\r
 100 \r
 101 > > In my configuration, I simply have a bash script in ~/.bin that simply\r
 102 > > runs offlineimap followed by notmuch new. This works quite nicely.\r
 103 > \r
 104 > This is essentially the same situation as with slocate, which has to\r
 105 > be run from cron currently, and hence gets outdated regularly.\r
 106 > Compare this to a hypothetical filesystem that exposed an index of\r
 107 > filenames (or content even!) to user-space, which could be used to\r
 108 > quickly search for files in real-time without the need to run\r
 109 > regular updates. I know other operating systems that have this\r
 110 > functionality already.\r
 111 > \r
 112 > Anyway, this is going off on a tangent, I feel.\r
 113 > \r
 114 That might be true but that certainly won't stop. ;) One would think\r
 115 that it wouldn't be difficult to teach slocate about inotify. I briefly\r
 116 looked into this and found rlocate but quickly realized that it requires\r
 117 its own kernel module. Apparently this has been investigated[1] and\r
 118 the inotify watch count limit becomes an issue very quickly. I seem to\r
 119 recall, however, that there were some whispers on the LKML about adding\r
 120 an interface that would be more capable of supporting such a system. I\r
 121 can't seem to recall the details, however, and homework beckons.\r
 122 \r
 123 Cheers,\r
 124 \r
 125 - Ben\r