From: David Bremner <david@tethera.net>
To: notmuch@notmuchmail.org
Date: Tue, 15 Dec 2009 08:05:13 -0400
Message-ID: <87pr6gcuiu.fsf@pivot.cs.unb.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [notmuch] notmuch and imap [musing, no code :)]
Precedence: list


Recent discussions on IRC (I forget with whom, sorry), brought me back
to thinking about syncing notmuch with imap.  In addition to the flags
\Seen, \Answered, \Draft, \Deleted, and \Flagged, imap servers can
optionally support user defined keywords (i.e. tags). At least courier
and dovecot do.  These keywords are imap "atoms", which, without tracing
though the BNF [1] completely look like they can can have (ascii)
alphanumeric, and punctuation other than brackets, quotes and "%", "*".

So the mapping is relatively nice between notmuch tags and imap
keywords.

One idea I had was to extend some imap syncing program to sync to
notmuch. mbsync (confusingly also named isync) is a C based one. It is
indeed relatively easy to add a new backend; I made a new "notmuch"
driver for mbsync in an hour or so that is actually just a maildir
driver.  I am a little discouraged by some of mbsync code (there are
lots of places with a buffer hard-coded to size 16, with a comment to
change that later when keyword support is added), but in principle, I
think this could work.  A more fundamental issue is that mbsync, like
most similar programs uses an index file to keep track of the sync
state, and it seems somehow wrong (or at least fragile) to keep a second
database with essentially the same information in it.

To write a custom sync program would require some imap code; this is
somewhere between trivial and not; mbsync's imap driver is about 1900
lines of C.  There is the uw c-client library; I remember some security
issues but that was more than a decade ago.  There are some newer
libraries like tinymail and libetpan, but they seem to have a whole
bunch of stuff not needed for notmuch.

d


[1]: http://www.faqs.org/rfcs/rfc3501.html