On Feb 27, 2015, at 3:09 PM, Peter Lebbing wrote: > On 27/02/15 12:02, Hans-Christoph Steiner wrote: >> For example, I think that >> `gpg --json` is great idea. I ended up using a Java wrapper of GPGME, which >> is in turn a wrapper of GnuPG. I think it makes a lot more sense to have >> `gpg >> --json` as the parseble interface, then implement a GPGME-style framework in >> each language (Python, Java, etc). > > I'd say the JSON interface could just be an additional set of functions in > GPGME; and GPGME simply talks the old colon-separated protocol to the gpg > binary. You can't just take out the colon-separated protocol, and that > protocol > has all the information. You could simply have GPGME reformat the output. > > Unless you mean that you want to speak to the gpg binary yourself, without > GPGME > in between. In that, case, I simply think you might be on the wrong track, and > should use a library. If GPGME itself is a problem because you don't know what > platform you should compile for, like in Python, then the library could be > re-implemented in pure Python instead of using a foreign function interface. > > The old calling conventions of the binary cannot change, otherwise you'd break > everything that already depends on it. And adding multiple ways of doing the > same thing in the gpg binary seems the wrong place; more code, more chance of > bugs, etcetera. This is where libraries come in, to save you the burden of > working with the gpg binary.
It is actually more difficult to wrap GPGME in Java than to have just rewritten GPGME in Java. GPGME is a fine API for C/C++, it is a bad API for other languages. You end up with an API that feels like a C API forced into the language, e.g. Java, python, etc. That makes for more coding mistakes because it feels foreign to the programmer. More mistakes means more security issues. .hc _______________________________________________ Gnupg-users mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnupg-users
