Mario Lenz <[EMAIL PROTECTED]> writes: > Hi! > >> In particular, OpenCDK isn't really in the shape that I'd >> like to see it in. Funding someone to work on that (I'm available :)) >> would be one way. > > Well, maybe I could spare some time to help you. What is you don't like > about OpenCDK? And what is it intended to *do* exactly? A definition of > the main programming goal would be a start. For example: I'm using > OpenCDK to get keys out of a keyring and use them with libgcrypt. Is > this it, and the encrypt/decrypt/sign/whatever functions are goodies, or > is it the other way round?
My general uneasiness around OpenCDK stems from the same kind of questions, which appear to be unanswered... Starting a texinfo manual for OpenCDK, with some general introductions to what OpenCDK aims to be would be immensely useful. It seems as if OpenCDK duplicate some of the functionality that properly belong to GnuPG. However, as far as I know, there aren't any APIs in GnuPG to do what OpenCDK does, even if the functionality is there. A serious question would be if we want to continue maintain OpenCDK at all. Making the same functionality be available from some GnuPG component could give some advantages -- such as smartcard support, gpg-agent support for passphrase caching, and hopefully better maintained code. Right now I keep maintaining OpenCDK because we are stuck with it, and that approach rarely results in the best products... I don't really have any thoughts about the code, I haven't looked hard enough to really have a feeling of it. I have a general preference to use gnulib, though, and using gnulib modules where appropriate, and there are some stuff in opencdk that could be replaced with some gnulib module. /Simon _______________________________________________ Help-gnutls mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-gnutls
