[PATCH v2 5/5] cli: lazily create the crypto gpg context only when needed

[Daniel Kahn Gillmor]

On 05/18/2012 03:45 PM, Jameson Graef Rollins wrote:
> On Fri, May 18 2012, Austin Clements <amdragon at MIT.EDU> wrote:
>> It's slightly awkward that it's the caller's responsibility to free
>> this lazily constructed object.  That should probably be documented.
>> We could more carefully reference count it, but I think that would
>> actually be worse because the reference count would probably bounce
>> through zero frequently.
> 
> I agree that this is awkward.  Is there a suggestion on how to do it
> better?  We only want to initialize it if it's needed, and only
> _mime_node_create knows that.  And we don't want to free it with
> _mime_node_context_free, or something, only to have to reinitialize it
> again with the next node or message.  Thoughts?

You could provide a "destructor" function for notmuch_crypto_t, which
whoever is responsible for the struct would need to call when they are
ready to dispose of it.

The destructor would just destroy any GMIME crypto contexts pointed to
by the struct, and reset those pointers to NULL.

Since the common workflow is a singleton notmuch_crypto_t that is a
subobject of the singleton notmuch_params_t, you could just call that
destructor function before the notmuch_params_t falls out of scope.

If you want to be fancy/symmetric, you could use the same pattern to
create a "destructor" function for notmuch_params_t (it would just
invoke the destructor on its crypto member), but this seems like
overkill to me, and not in line with the talloc approach of the rest of
the codebase.

I agree that it's a little awkward, but i think there's something of an
impedance mismatch between gmime's object interface and notmuch's use of
talloc and friends.

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1030 bytes
Desc: OpenPGP digital signature
URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20120518/4fd3f976/attachment-0001.pgp>