From: Carl Worth <cworth@cworth.org>
To: Michal Sojka <sojkam1@fel.cvut.cz>, notmuch@notmuchmail.org
Subject: Re: [PATCH v4 0/4] Maildir synchronization
In-Reply-To: <1288560558-18915-1-git-send-email-sojkam1@fel.cvut.cz>
References: <87tyk3vpxd.fsf@wsheee.2x.cz>
	<1288560558-18915-1-git-send-email-sojkam1@fel.cvut.cz>
User-Agent: Notmuch/0.4 (http://notmuchmail.org) Emacs/23.2.1
	(i486-pc-linux-gnu)
Date: Thu, 04 Nov 2010 12:16:25 -0700
Message-ID: <877hgsrjau.fsf@yoom.home.cworth.org>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
	micalg=pgp-sha1; protocol="application/pgp-signature"
Precedence: list

--=-=-=
Content-Transfer-Encoding: quoted-printable

On Sun, 31 Oct 2010 22:29:14 +0100, Michal Sojka <sojkam1@fel.cvut.cz> wrot=
e:
> This is the next iteration of maildir synchronization patches. The
> changes are:
> - Configuration is now simplified. The synchronization can only be
>   full enabled or disabled. By default it is still disabled.
> - Added test for notmuch restore (with enabled synchronization)
> - Rebased to the current master
> - 'D' flag is mapped to 'deleted' tag instead of 'delete' (this has
>   already been in v3)

This is coming along nicely, Michal. I'm delighted to see the testing
here and the improved configuration support.

I think after merging this, I'd be inclined to change two tiny things:

	1. Enable it by default

	2. Augment the documentation in the configuration file to say
	   exactly which tags are synchronized with which flags.

I could easily do those in follow-up commits, so there's no need to
worry about resending the series for those.

Meanwhile, here are some of the things I'm still thinking about in
regards to this patch. First, the commit message describes the
synchronization happening at "notmuch new" and "notmuch tag/notmuch
restore". But the implementation shows that the functionality is within
the library, not the command-line tool above it.

I think having this at the library makes sense, but as you certainly
noticed, the library has historically been entirely unaware of any
configuration, (which I'd like to keep). Obviously, you maintained that
separation in your patch series, but you added a new
notmuch_database_set_maildir_sync function so that the library can be
informed of the desired behavior.

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.

Also, the synchronization is inherently 2-way, but the two directions
are implemented differently in the library. One direction, (from tags to
maildir flags), is implemented implicitly in the library (existing
functions do the new synchronization under the influence of
database_set_maildir_sync). But the other direction, (from maildir flags
to tags), requires an explicit call to a new function
(notmuch_message_maildir_to_flags). I definitely don't like this.

Finally, the documentation for notmuch_message_maildir_to_tags ("Add or
remove tags based on the maildir flags in the file name")
inadequate. This documentation needs to say which tags are added/removed
in what conditions. It should also give guidance on when this function
should be called in order to achieve some particular behavior.

I recognize that in the above I don't give specific guidance on whether
the new functionality should be implicit or explicit in the
library. I'm not certain which is better, and I'm willing to listen to
justification from someone who has spent some time implementing and
testing this stuff. But I don't like the current mixed state.

One other issue, how does this support deal with multiple files that
have the same message ID (and hence a single record in the database)?
Some bad failure modes I can imagine are cycling of tags/filenames with
successive runs of notmuch new, or "leaking"[*] of tags from one filename
to another through the database.

[*] Imagine, for example, someone using an external client that
identifies duplicate messages in the mailstore and adds the maildir flag
corresponding to "deleted" to all but one of each of the
duplicates. There's then the possibility that notmuch could propagate
this "deleted" flag through the "deleted" tag in the database, (perhaps
after a notmuch dump/restore cycle). And that could be a catastrophic
result if all messages that have duplicates get flagged for deletion!

What thoughts do you have on this multiple-file issue?

=2DCarl

=2D-=20
carl.d.worth@intel.com

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iD8DBQFM0waJ6JDdNq8qSWgRAk6XAKCn70p+NWXp1vi/cJZisS0fUUmHEgCgqoEw
352iR5Y5KX9vlbjlNV2VW1M=
=36xL
-----END PGP SIGNATURE-----
--=-=-=--