Return-Path: X-Original-To: notmuch@notmuchmail.org Delivered-To: notmuch@notmuchmail.org Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id 62EE740DAF4 for ; Mon, 8 Nov 2010 14:03:34 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: -2.89 X-Spam-Level: X-Spam-Status: No, score=-2.89 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, T_MIME_NO_TEXT=0.01] autolearn=ham Received: from olra.theworths.org ([127.0.0.1]) by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5KqKjTiaMAT3; Mon, 8 Nov 2010 14:03:22 -0800 (PST) Received: from yoom.home.cworth.org (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id F33D140DACC; Mon, 8 Nov 2010 14:03:21 -0800 (PST) Received: by yoom.home.cworth.org (Postfix, from userid 1000) id A347225412C; Mon, 8 Nov 2010 11:35:18 -0800 (PST) From: Carl Worth To: Michal Sojka , notmuch@notmuchmail.org Subject: Re: [PATCH v4 0/4] Maildir synchronization In-Reply-To: <87d3qhq527.fsf@resox.2x.cz> References: <87tyk3vpxd.fsf@wsheee.2x.cz> <1288560558-18915-1-git-send-email-sojkam1@fel.cvut.cz> <877hgsrjau.fsf@yoom.home.cworth.org> <87d3qhq527.fsf@resox.2x.cz> User-Agent: Notmuch/0.4 (http://notmuchmail.org) Emacs/23.2.1 (i486-pc-linux-gnu) Date: Mon, 08 Nov 2010 11:35:18 -0800 Message-ID: <874obrmww9.fsf@yoom.home.cworth.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2010 22:03:34 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable On Sun, 07 Nov 2010 02:46:08 +0100, Michal Sojka wrot= e: > 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. >=20 > I can imagine two other solutions. One would be to add a parameter > (probably called flags) to the following functions: >=20 > 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, =2DCarl =2D-=20 carl.d.worth@intel.com --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iD8DBQFM2FD26JDdNq8qSWgRAqFpAJ9yhb5LuyC/LX+FCrb4dcY4bxOvxgCfRVzk gmDXmtJz30XWY2aHp/WkOhs= =f45/ -----END PGP SIGNATURE----- --=-=-=--