2002-02-09 Marcus Brinkmann <marcus@g10code.de>
[gpgme.git] / TODO
diff --git a/TODO b/TODO
index ff94928..0f97bae 100644 (file)
--- a/TODO
+++ b/TODO
@@ -1,39 +1,17 @@
+Hey Emacs, this is -*- outline -*- mode!
+
 * 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?
-** keylisting mode can go
-** api to specify where to search, lokal and/or remote.
-
-* Implement posix-sema.c
 
 * Allow to use GTK's main loop instead of the select stuff in
   wait.c
 
 * add locking to the key cache?
 
-* Should --delete silently delete secret keys or is there a need for
-  another flag or a callback?
-
 * GpgmeKey misses GPGME_ATTR_EXPIRE attribute
 
-* Add ATTR to return the number of subkeys or uids.
-
-* Return GPGME_Canceled when appropriate
-
-* Factor out common code in _op_*_start functions.
-
 * Documentation
 ** Add note about GPGME clearing out pointer return values.
 ** validity/trust
    (it's an internal error, as select_protocol checks already).
 
 * Operations
-** Import, export status handler.
+** Export status handler need much more work.
+** Import should return a useful error when one happened.
+** Genkey should return something more useful than General_Error.
+** Factor out common code in _op_*_start functions.
+** Add ATTR to return the number of subkeys or uids.
+** "When returning a GpgmeKey GPGME_ATTR_COMMENT attribute, characters  
+   like ":" are not un-escaped, they are returned as \x3a" Bug
+   reported by Stephane Corthesy.
+
 
 * Error Values
-** Map ASSUAN error values.
-** Map GpgSM ERR messages.
+** Map ASSUAN/GpgSM ERR error values in a better way than is done now.
 ** Verify (and document) if Read_Error, Write_Error, Pipe_Error set errno.
+** "There is an inconsistent behaviour: if we pass three times an  
+   invalid (but non empty) passphrase, return code is GPGME_No_Data,
+   but if we pass three times an empty (and invalid) passphrase, we
+   get GPGME_No_Passphrase." Bug reported by Stephane Corthesy.
 
 * Tests
 ** t-data
 
 * Build suite
 ** Make sure everything is cleaned correctly (esp. test area).
+** There is a spurious 4/10 tests failed in some conditions.
+   Rebuilding from scratch works around that.
 
-Bugs reported by Stephane Corthesy:
-> - When returning a GpgmeKey GPGME_ATTR_COMMENT attribute, characters  
-> like ":" are not un-escaped, they are returned as \x3a
+* Architecture support
+** Implement posix-sema.c
 
+Bugs reported by Stephane Corthesy:
 > BTW, here's another bug: it it not possible to retrieve fingerprints  
 > for subkeys
 
@@ -71,18 +62,8 @@ Bugs reported by Stephane Corthesy:
 > would return the validity assigned to a name contained in the  
 > GpgmeRecipients instance?
 
-> - There is an inconsistent behaviour: if we pass three times an  
-> invalid (but non empty) passphrase, return code is GPGME_No_Data, but  
-> if we pass three times an empty (and invalid) passphrase, we get  
-> GPGME_No_Passphrase.
-
 > passphrase callback. If I use the same GpgmeContext as the one which  
 > is currently asking for a passphrase, my app crashes: the r_hd in
 > 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.