On Sun, 07 Nov 2010 02:46:08 +0100, Michal Sojka <sojkam1@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@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@intel.com