57/cea560245f9207786147e972c1ff4f29d3e6a9

   1 Return-Path: <eg@gaute.vetsj.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 14776431FC0\r
   6         for <notmuch@notmuchmail.org>; Wed, 23 Apr 2014 00:25:55 -0700 (PDT)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: -0.7\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5\r
  12         tests=[RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled\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 2DqV4pF7ed4b for <notmuch@notmuchmail.org>;\r
  16         Wed, 23 Apr 2014 00:25:51 -0700 (PDT)\r
  17 Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com\r
  18         [209.85.217.176]) (using TLSv1 with cipher RC4-SHA (128/128 bits))\r
  19         (No client certificate requested)\r
  20         by olra.theworths.org (Postfix) with ESMTPS id BEBC8431FBF\r
  21         for <notmuch@notmuchmail.org>; Wed, 23 Apr 2014 00:25:50 -0700 (PDT)\r
  22 Received: by mail-lb0-f176.google.com with SMTP id 10so433444lbg.21\r
  23         for <notmuch@notmuchmail.org>; Wed, 23 Apr 2014 00:25:48 -0700 (PDT)\r
  24 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;\r
  25         d=1e100.net; s=20130820;\r
  26         h=x-gm-message-state:content-type:from:to:subject:references\r
  27         :in-reply-to:date:message-id:user-agent:content-transfer-encoding;\r
  28         bh=rl7IkXb7kNG9YxdvTR4GX3Gq5yQ5B3EEkLVU7heUdjI=;\r
  29         b=enHgYlaMQj9aqi5dzi6P9cOhGKxd+lqAbCSX704GG0rzAlwhp41WIqTZ531U8nn0IU\r
  30         xhXUvn551Pl9ua8A9lfPHtYwi1NNTTNg1SMGGv269Per0FZnxdipO5o6X4p4QOdG+190\r
  31         BtS9/2f26JVDw7+MPFL+fn3GqClCWqMSnZgoPnU38x4jFStsgNgudtffatfyHMJ/vQ15\r
  32         E+KfAjuhhTn/QzgxY2N+rlhllkl3cDc4yqc3JDpmH3A5pjPS/jTtEnpygbiHQhYRLcZU\r
  33         EJt+H7D95aqo/wKJRDR3uINUWu1wxRTYQcKfBF9AxQyTCRTMyEVsGsoZiq7mLBdogztU\r
  34         H0+g==\r
  35 X-Gm-Message-State:\r
  36  ALoCoQl7NZ6hFFRtufMFCLIMs+3daCWatz0GiIxgB6Xvi8kkacyA7jYMmpkG0+3pKKYzG5giiytY\r
  37 X-Received: by 10.112.95.166 with SMTP id dl6mr1168865lbb.19.1398237946930;\r
  38         Wed, 23 Apr 2014 00:25:46 -0700 (PDT)\r
  39 Received: from localhost ([128.39.46.106])\r
  40         by mx.google.com with ESMTPSA id fa8sm176087lbc.18.2014.04.23.00.25.45\r
  41         for <multiple recipients>\r
  42         (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\r
  43         Wed, 23 Apr 2014 00:25:46 -0700 (PDT)\r
  44 Content-Type: text/plain; charset=UTF-8\r
  45 From: Gaute Hope <eg@gaute.vetsj.com>\r
  46 To: David Bremner <david@tethera.net>, notmuch <notmuch@notmuchmail.org>\r
  47 Subject: Re: [PATCH] Add configurable changed tag to messages that have been\r
  48         changed on disk\r
  49 References: <1396800683-9164-1-git-send-email-eg@gaute.vetsj.com>\r
  50         <87wqf2gqig.fsf@ta.scs.stanford.edu> <1397140962-sup-6514@qwerzila>\r
  51         <87wqexnqvb.fsf@ta.scs.stanford.edu> <1397163239-sup-5101@qwerzila>\r
  52         <87d2g9ja0h.fsf@maritornes.cs.unb.ca>\r
  53 In-reply-to: <87d2g9ja0h.fsf@maritornes.cs.unb.ca>\r
  54 Date: Wed, 23 Apr 2014 09:24:40 +0200\r
  55 Message-Id: <1398237865-sup-624@qwerzila>\r
  56 User-Agent: Sup/git\r
  57 Content-Transfer-Encoding: 8bit\r
  58 X-BeenThere: notmuch@notmuchmail.org\r
  59 X-Mailman-Version: 2.1.13\r
  60 Precedence: list\r
  61 List-Id: "Use and development of the notmuch mail system."\r
  62         <notmuch.notmuchmail.org>\r
  63 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  64         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  65 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  66 List-Post: <mailto:notmuch@notmuchmail.org>\r
  67 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  68 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  69         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  70 X-List-Received-Date: Wed, 23 Apr 2014 07:25:55 -0000\r
  71 \r
  72 Excerpts from David Bremner's message of 2014-04-23 00:05:02 +0200:\r
  73 > Gaute Hope <eg@gaute.vetsj.com> writes:\r
  74 >\r
  75 > >\r
  76 > > I am talking about syncing tags to a maildir _folder_, not flags. It\r
  77 > > could be implemented as maildir.synchronize is now, but it would be a\r
  78 > > larger feature which could work in a lot of different ways.\r
  79 > >\r
  80 >\r
  81 > So to try and clarify the use case, this could be used to add a tag\r
  82 > "changed" to each message-id that had one or more files\r
  83 > moved/added/deleted on disk.  You would then retag that message using\r
  84 > something like the output of notmuch search --output=files so that a set\r
  85 > of tags corresponds to a set of folders containing the message. Is this\r
  86 > correct?   I guess the proposed ctime information could be used for this\r
  87 > as well, if it also tracked those non-tag related changes. I guess this\r
  88 > would make it worse for David M's purposes (although presumeably still\r
  89 > better than nothing).\r
  90 \r
  91 Yes, I would not know what has changed, but I would know which messages\r
  92 to check for changes and then decide whether and how to re-tag it. For\r
  93 the opposite case, when a message has been changed locally by a client\r
  94 and I would want to decide whether I need to copy/move/delete the\r
  95 message based on the tags a tag could be added by the application.\r
  96 \r
  97 In response to the issue of cost of this operation: I don't think it\r
  98 will differ much from how 'new' is handled at the moment.\r
  99 \r
 100 One extension perhaps worth considering is to have ctimes on each source\r
 101 file as well as the db entry, but it might be overkill.\r
 102 \r
 103 I still strongly favor an intenal db-tick over ctime - or store both,\r
 104 the application iterating over the 'changed' tag (or messages changed\r
 105 since last time) would have to store the time of last check as well. A\r
 106 whole bunch of stuff could result in this time being inaccurate,\r
 107 especially if these run on different machines.\r
 108 \r
 109 A db-tick or a _good_ ctime solution can as far as I can see solve both\r
 110 David M's (correct me if I am wrong) and my purposes, as well as\r
 111 probably have more use cases in the future. It would even be an\r
 112 interesting direct search: show me everything that changed lately,\r
 113 sorted.\r
 114 \r
 115 As noted before, my use case could also be solved by implementing it in\r
 116 a similar fashion as sync_flags are now, is it possible to hook into\r
 117 this stage in some way? So that it does not need to be included in\r
 118 core notmuch.\r
 119 \r
 120 - gaute\r