allow indexing cleartext of encrypted messages

[Daniel Kahn Gillmor]

On Wed 2015-12-09 22:39:37 -0500, Daniel Kahn Gillmor wrote:
>  * the libnotmuch API is extended with
>    notmuch_database_add_message_try_decrypt().  This should probably
>    ultimately be more general, because there are a few additional
>    knobs that i can imagine fiddling at indexing time.  For example:
>
>     * verifying cryptographic signatures and storing something about
>       those verifications in the notmuch db
>      
>     * extracting OpenPGP session key information for a given message
>       and storing it in a lookaside table in the notmuch db, so that
>       it's possible to securely destroy old encryption-capable keys
>       and still have local access to the cleartext of the remaining
>       messages.
>
>    Some of these additional features might be orthogonal to one
>    another as well.  I welcome suggestions for how to improve the API
>    so that we don't end up with a combinatorial explosion of
>    n_d_add_message_foo() functions.

I have a proposal for how to do this better:

I'll introduce a notmuch_index_options_t, with the usual constructors
and destructors and a couple functions:

  notmuch_index_options_set_try_decrypt()
  notmuch_index_options_get_try_decrypt()
  notmuch_index_options_set_gpg_path()
  notmuch_index_options_get_gpg_path()

Then i'll add:

  notmuch_database_add_message_with_options(db, fname, options, &message)

If we add new indexing features, they can be set directly in the
index_options object (including features that might be more complex than
a string or a bool, like a chain of command-line filters).

a few nice features of this approach:

 * The user of the library can craft a set of index options and repeat
   it easily, and the options can contain cached/lazily-initialized
   things (like GMimeCryptoContexts) if needed.

 * The user can index different messages with different options if they
   prefer (no need to set the options on the database object itself)

 * the capability of the indexing features in the library is visible
   directly in the exposed API.

any thoughts on this?

    --dkg