On Wed, 24 Feb 2010 10:19:06 -0800, Carl Worth <cworth@cworth.org> wrote:
> Elsewhere in the thread Jameson Rollins wrote:
> > I should have mentioned in my previous mail that I think this tool is
> > a great idea, and I plan on using it.  I just hope that all of it's
> > functionality will be integrated directly into notmuch itself.
> 
> I think that's the open question still. How much of this kind of
> functionality do we integrate into notmuch itself. I don't know the
> answer to that question yet, but I'm quite happy to see people
> experimenting with doing scripts like this on top of notmuch already.

Hi, when you are on this topic, I'll put my two cents in. Currently
notmuch works only with mail-store comprised of files. People want to
work with their mails on multiple computers so there are several
ideas/solutions how to achieve that. Notmuchsync, which plays well with
offlineimap, is one of them. Another idea is Git based mail-store, which
I would really like to have.

If we want to make notmuch work with Git-based mail-store, it will be
necessary to make the interface between notmuch core and mail-store
handling code a bit more abstract so that it will be possible to
configure mail-store type to be used.

This abstract mail-store interface will contain methods for the
following operations:
1. read mail identified by a path from mail-store
   (current notmuch uses fread() for this, for git this will be
   something like system("git cat-file ..."))
2. get the list of new mails which need to be indexed
   (current notmuch does recursive file traversal, for git-based store
   it will be something like system("git diff-tree --name-status ...")
3. add/remove tags for a given message (this will be NULL for current
   notmuch functionality)

This way the mail-store will be able to store both mails and
corresponding tags and in case of git, it will be easy to synchronize
mail-stores on multiple computers.

Now, if we have this, it would be very easy to add support for
Maildir-based mail-store. The implementation of the first two methods
would be the same as what is currently in notmuch and the third method
would rename files in mailstore if certain tags (such as unread) are
added or removed. In case of rename, notmuch database would be
immediately updated to reflect the change.

So to summarize, I think there should be an abstract layer for
handling different types of mail-store. I can see at least three
possible implementations of this abstract interface: 1) immutable
mail-store (as currently implemented in notmuch) 2) Maildir-based
mail-store for limited synchronization with other Maildir tools and 
3) git-based mail-store for full synchronization.

I've already started working on this, but I'm still in the state where I
mainly study how notmuch works in order not to break its current
functionality.

I'd like to hear what others think about this idea.

Bye
Michal