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