+* ABI's to break:
+** gpgme_data_new_from_filepart takes an off_t as count, but should
+ take a size_t.
+** GpgmePassphraseCb should have void **R_HD, not void *R_HD.
+** trustlist has the same start/end problem as keylist had.
+ In fact, all the _start functions have this problem!
+ In addition, the resulting error of the operation can not be
+ retrieved seperately; the op_foobar operations can't be implemented
+ by the user, they are not merely convenience, but necessity, while
+ the op_foobar_start functions for these are unusable (or render the
+ context unusable, your choice).
+** string representation of non-secret keys and ATTR_IS_SECRET is NULL,
+ which can not be differentiated from the case that it is not
+ representable.
+** Agree on gpgme_key_unref or gpgme_key_release and drop the other?
+
* Implement posix-sema.c
* Allow to use GTK's main loop instead of the select stuff in
* Factor out common code in _op_*_start functions.
-* Move code common to all engines up from gpg to engine.
+* Documentation
+** Add note about GPGME clearing out pointer return values.
+** validity/trust
+
+* Engines
+** Move code common to all engines up from gpg to engine.
+** engine operations can return General Error on unknown protocol
+ (it's an internal error, as select_protocol checks already).
* Error Values
** Map ASSUAN error values.
> the
> callback has become invalid; if I use a brand new one, the callback
> is called recursively, when I ask to enumerate keys.
+
+> Talking about gpgme performances: did anyone make some profiling on
+> gpgme calls and can tell me why it takes so long to enumerate the
+> whole pubring? Listing keys with gpg is very fast, whereas with
+> gpgme_op_keylist_XXX() it's soooooo slow.