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. HTH, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at <http://digitalbrains.com/2012/openpgp-key-peter> _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
