+** Old opassuan interface.
+** Implementation: Remove support for old style error codes in
+ conversion.c::_gpgme_map_gnupg_error.
+** gpgme_edit_cb_t: Add "processed" return argument
+ (see edit.c::command_handler).
+** I/O and User Data could be made extensible. But this can be done
+ without breaking the ABI hopefully.
+** All enums should be replaced by ints and simple macros for
+ maximum compatibility.
+** Compatibility interfaces that can be removed in future versions:
+*** gpgme_data_new_from_filepart
+*** gpgme_data_new_from_file
+*** gpgme_data_new_with_read_cb
+*** gpgme_data_rewind
+*** gpgme_op_import_ext
+*** gpgme_get_sig_key
+*** gpgme_get_sig_ulong_attr
+*** gpgme_get_sig_string_attr
+*** GPGME_SIG_STAT_*
+*** gpgme_get_sig_status
+*** gpgme_trust_item_release
+*** gpgme_trust_item_get_string_attr
+*** gpgme_trust_item_get_ulong_attr
+*** gpgme_attr_t
+*** All Gpgme* typedefs.
+
+
+* Thread support:
+** When GNU Pth supports sendmsg/recvmsg, wrap them properly.
+** Without timegm (3) support our ISO time parser is not thread safe.
+ There is a configure time warning, though.
+
+* New features:
+** Flow control for data objects.
+ Currently, gpgme_data_t objects are assumed to be blocking. To
+ break this assumption, we need either (A) a way for an user I/O
+ callback to store the current operation in a continuation that can
+ be resumed later. While the continuation exists, file descriptors
+ associated with this operation must be removed from their
+ respective event loop. or (B) a way for gpgme data objects to be
+ associated with a waitable object, that can be registered with the
+ user event loop. Neither is particularly simple.
+** Extended notation support. When gpg supports arbitrary binary
+ notation data, provide a user interface for that.
+** notification system
+ We need a simple notification system, probably a simple callback
+ with a string and some optional arguments. This is for example
+ required to notify an application of a changed smartcard, The
+ application can then do whatever is required. There are other
+ usages too. This notfication system should be independent of any
+ contextes of course.
+
+ Not sure whether this is still required. GPGME_PROTOCOL_ASSUAN is
+ sufficient for this.