Date: Sat, 24 Dec 2011 14:03:15 -0500
From: Austin Clements <amdragon@MIT.EDU>
To: Jameson Graef Rollins <jrollins@finestructure.net>
Subject: Re: [PATCH v4 2/4] Introduce a generic tree-like abstraction for
	MIME traversal.
Message-ID: <20111224190315.GE1927@mit.edu>
References: <1323460468-4030-1-git-send-email-amdragon@mit.edu>
	<1324698348-27620-1-git-send-email-amdragon@mit.edu>
	<1324698348-27620-3-git-send-email-amdragon@mit.edu>
	<87y5u2jte1.fsf@servo.finestructure.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87y5u2jte1.fsf@servo.finestructure.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: notmuch@notmuchmail.org
Precedence: list

Quoth Jameson Graef Rollins on Dec 23 at 11:55 pm:
> On Fri, 23 Dec 2011 22:45:46 -0500, Austin Clements <amdragon@MIT.EDU> wrote:
> > +    /* True if decryption of this part was attempted. */
> > +    notmuch_bool_t decrypt_attempted;
> > +    /* True if decryption of this part's child succeeded.  In this
> > +     * case, the decrypted part is substituted for the second child of
> > +     * this part (which would usually be the encrypted data). */
> > +    notmuch_bool_t decrypt_success;
> > +
> > +    /* True if signature verification on this part was attempted. */
> > +    notmuch_bool_t sig_attempted;
> 
> I think these new variables make sense, and reflect the correct
> semantics, as you already mentioned.
> 
> I do, however, think the later variable should be called
> "verify_attempted" (or "verification_", or "ver_"?), instead of
> "sig_attempted", since verification is the complementary action on a
> signed part, just as decryption is for an encrypted one.
> "sig_attempted" somehow implies to me that one is trying to make a
> signature, not verify an existing one.

The intent was to parallel sig_validity, but I see your point.  v5
with verify_attempted will be coming along soon (when our power comes
back).