[PATCH v4 0/4] Maildir synchronization

[Carl Worth]

On Sun, 07 Nov 2010 02:46:08 +0100, Michal Sojka <sojkam1 at fel.cvut.cz> wrote:
> On Thu, 04 Nov 2010, Carl Worth wrote:
> > I'm not entirely sure I like a big, global state-changing function like
> > that in the library. But if we do want to have that, we need to fix the
> > documentation of all functions that are affected by it to correctly
> > document their current behavior.
> 
> I can imagine two other solutions. One would be to add a parameter
> (probably called flags) to the following functions:
> 
>     notmuch_message_add_tag()
>     notmuch_message_remove_tag()
>     notmuch_message_thaw()
...
> The other option would be to put a flag into notmuch_message_t but this
> is probably not very different from having it in notmuch_database_t.

Here's yet another approach that I have in mind.

We can implement all of the support by adding two new library functions:

	notmuch_database_add_message_with_maildir_flags
	notmuch_message_sync_with_maildir_flags

These functions would work like the existing
notmuch_database_add_message and notmuch_message_sync except they would
do the maildir-flag synchronization.

This allows a user of the library to do whatever it wants, (no
synchronization, one-way synchronization in either direction, or two-way
synchronization), without having any sort of "configuration" API calls
in the library.

> I think I could make notmuch_message_maildir_to_flags() private and call
> it from notmuch_database_add_message() so that both directions will be
> implemented in the library.

Yes. That's in line with what I propose above.

> The current implementation renames only the file whose name is stored
> first in the database. I have a TODO comment there to add a loop through
> all file names, but I have never realized that deleted flag could be so
> dangerous.

I think what I'd like to do for now is to simply remove "deleted" from
the set of tags being manipulated by this support. This is the similar
to what Sebastian decided to do with notmuchsync when he described in
detail the same scenario I was concerned with:

	id:87eickhor1.fsf at SSpaeth.de

Sebastian's solution was slightly different, ("deleted" was not
synchronized by default but could be explicitly requested). I propose
simply not synchronizing "deleted" until it can be made safe.

> It will take me probably a few days until I find time to work on this.
> So let me now in that time whether you have some preferences in the
> above.

I'd like to get things merged today, so I plan to take your patches and
then add new commits on top to implement the functions I described
above.

I'll be interested in any feedback.

Thanks again,

-Carl

-- 
carl.d.worth at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20101108/354d8d92/attachment.pgp>