On Fri, Dec 11 2015, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote: > 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? sounds good (on paper) (*) > > --dkg Tomi (*) deliberately declined to write 'looks good' >;) (but it's good)