Re: [notmuch] tag dir proposal [was: Re: Git as notmuch object store]

Subject: Re: [notmuch] tag dir proposal [was: Re: Git as notmuch object store]

Date: Thu, 28 Jan 2010 18:10:57 +1300

To: Jameson Rollins

Cc: notmuch

From: martin f krafft


also sprach Jameson Rollins <jrollins@finestructure.net> [2010.01.26.1046 +1300]:
> > For example, I might have:
> > 
> > ~/.notmuch-config:
> > 
> >     [database]
> >     path=/home/pioto/mail
> >     ...
> >     [tags]
> >     pioto@pioto.org/INBOX.ListMail.notmuch = notmuch
> > 
> > So, a 'tags' section, where each key is the folder name, relative to the
> > db path, and the value is one or more tag names
> 
> I think this idea is a really good one and I would like to pursue it as
> a tangent thread here.  I was going to propose something very similar to
> this.  I think it's a very flexible idea that would help in a lot of
> ways.

I think we need to carefully distinguish here. The above seems to
suggest a mapping from folder to tag, but we don't actually need
tags for folder locations, because those can (and should) be
implicitly determined from the database and storing the tag in
addition would just run the risk of getting out of sync: if I moved
a message, I would also have to remember to delete old and add new
tags, which is just asking for trouble.

> [tags]
> inbox = +inbox,+unread
> sent = +sent
> drafts = +draft
> archive = -inbox

This proposal, on the other hand, is an interesting one, but when is
it supposed to happen? It just feels wrong to make this happen as
part of 'notmuch new'.

What I would like to see is a notmuch-aware MDA, e.g. a programme
which reads an incoming mail on stdin and can do all this kind of
stuff, e.g. assign tags based on such rules (or take tags as
arguments, so that I could trivially set tags from procmail too),
write the message to the message store, and update the database.

This would allow us to get rid of 'notmuch new' altogether, at least
conceptually. We'd still need it if mail is being delivered
independently, e.g. with offlineimap.

On the performance side, it might make sense to write to a journal
instead of updating the database every time. SpamAssassin does this
with its Bayesian database, and it only merges the journal every
X updates (or when the user manually requests it). I am not sure
whether this is possible with Xapian. On the other hand, I think
notmuch needs to learn to journal anyway so that we can keep
different instances in sync.

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
"the only way to get rid of a temptation is to yield to it."
                                                        -- oscar wilde
 
spamtraps: madduck.bogus@madduck.net
digital_signature_gpg.asc (application/pgp-signature)

Thread: