Return-Path: <eg@gaute.vetsj.com>
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 14776431FC0
	for <notmuch@notmuchmail.org>; Wed, 23 Apr 2014 00:25:55 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at olra.theworths.org
X-Spam-Flag: NO
X-Spam-Score: -0.7
X-Spam-Level: 
X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5
	tests=[RCVD_IN_DNSWL_LOW=-0.7] 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 2DqV4pF7ed4b for <notmuch@notmuchmail.org>;
	Wed, 23 Apr 2014 00:25:51 -0700 (PDT)
Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com
	[209.85.217.176]) (using TLSv1 with cipher RC4-SHA (128/128 bits))
	(No client certificate requested)
	by olra.theworths.org (Postfix) with ESMTPS id BEBC8431FBF
	for <notmuch@notmuchmail.org>; Wed, 23 Apr 2014 00:25:50 -0700 (PDT)
Received: by mail-lb0-f176.google.com with SMTP id 10so433444lbg.21
	for <notmuch@notmuchmail.org>; Wed, 23 Apr 2014 00:25:48 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:content-type:from:to:subject:references
	:in-reply-to:date:message-id:user-agent:content-transfer-encoding;
	bh=rl7IkXb7kNG9YxdvTR4GX3Gq5yQ5B3EEkLVU7heUdjI=;
	b=enHgYlaMQj9aqi5dzi6P9cOhGKxd+lqAbCSX704GG0rzAlwhp41WIqTZ531U8nn0IU
	xhXUvn551Pl9ua8A9lfPHtYwi1NNTTNg1SMGGv269Per0FZnxdipO5o6X4p4QOdG+190
	BtS9/2f26JVDw7+MPFL+fn3GqClCWqMSnZgoPnU38x4jFStsgNgudtffatfyHMJ/vQ15
	E+KfAjuhhTn/QzgxY2N+rlhllkl3cDc4yqc3JDpmH3A5pjPS/jTtEnpygbiHQhYRLcZU
	EJt+H7D95aqo/wKJRDR3uINUWu1wxRTYQcKfBF9AxQyTCRTMyEVsGsoZiq7mLBdogztU
	H0+g==
X-Gm-Message-State:
 ALoCoQl7NZ6hFFRtufMFCLIMs+3daCWatz0GiIxgB6Xvi8kkacyA7jYMmpkG0+3pKKYzG5giiytY
X-Received: by 10.112.95.166 with SMTP id dl6mr1168865lbb.19.1398237946930;
	Wed, 23 Apr 2014 00:25:46 -0700 (PDT)
Received: from localhost ([128.39.46.106])
	by mx.google.com with ESMTPSA id fa8sm176087lbc.18.2014.04.23.00.25.45
	for <multiple recipients>
	(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Wed, 23 Apr 2014 00:25:46 -0700 (PDT)
Content-Type: text/plain; charset=UTF-8
From: Gaute Hope <eg@gaute.vetsj.com>
To: David Bremner <david@tethera.net>, notmuch <notmuch@notmuchmail.org>
Subject: Re: [PATCH] Add configurable changed tag to messages that have been
	changed on disk
References: <1396800683-9164-1-git-send-email-eg@gaute.vetsj.com>
	<87wqf2gqig.fsf@ta.scs.stanford.edu> <1397140962-sup-6514@qwerzila>
	<87wqexnqvb.fsf@ta.scs.stanford.edu> <1397163239-sup-5101@qwerzila>
	<87d2g9ja0h.fsf@maritornes.cs.unb.ca>
In-reply-to: <87d2g9ja0h.fsf@maritornes.cs.unb.ca>
Date: Wed, 23 Apr 2014 09:24:40 +0200
Message-Id: <1398237865-sup-624@qwerzila>
User-Agent: Sup/git
Content-Transfer-Encoding: 8bit
X-BeenThere: notmuch@notmuchmail.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: "Use and development of the notmuch mail system."
	<notmuch.notmuchmail.org>
List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,
	<mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>
List-Archive: <http://notmuchmail.org/pipermail/notmuch>
List-Post: <mailto:notmuch@notmuchmail.org>
List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>
List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,
	<mailto:notmuch-request@notmuchmail.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Apr 2014 07:25:55 -0000

Excerpts from David Bremner's message of 2014-04-23 00:05:02 +0200:
> Gaute Hope <eg@gaute.vetsj.com> writes:
>
> >
> > I am talking about syncing tags to a maildir _folder_, not flags. It
> > could be implemented as maildir.synchronize is now, but it would be a
> > larger feature which could work in a lot of different ways.
> >
>
> So to try and clarify the use case, this could be used to add a tag
> "changed" to each message-id that had one or more files
> moved/added/deleted on disk.  You would then retag that message using
> something like the output of notmuch search --output=files so that a set
> of tags corresponds to a set of folders containing the message. Is this
> correct?   I guess the proposed ctime information could be used for this
> as well, if it also tracked those non-tag related changes. I guess this
> would make it worse for David M's purposes (although presumeably still
> better than nothing).

Yes, I would not know what has changed, but I would know which messages
to check for changes and then decide whether and how to re-tag it. For
the opposite case, when a message has been changed locally by a client
and I would want to decide whether I need to copy/move/delete the
message based on the tags a tag could be added by the application.

In response to the issue of cost of this operation: I don't think it
will differ much from how 'new' is handled at the moment.

One extension perhaps worth considering is to have ctimes on each source
file as well as the db entry, but it might be overkill.

I still strongly favor an intenal db-tick over ctime - or store both,
the application iterating over the 'changed' tag (or messages changed
since last time) would have to store the time of last check as well. A
whole bunch of stuff could result in this time being inaccurate,
especially if these run on different machines.

A db-tick or a _good_ ctime solution can as far as I can see solve both
David M's (correct me if I am wrong) and my purposes, as well as
probably have more use cases in the future. It would even be an
interesting direct search: show me everything that changed lately,
sorted.

As noted before, my use case could also be solved by implementing it in
a similar fashion as sync_flags are now, is it possible to hook into
this stage in some way? So that it does not need to be included in
core notmuch.

- gaute