Keyrings file format

[Marcus Brinkmann]

Hi,

David Paleino wrote:
> Also, I could've written a binding to libgpgme -- but that too reads gpg's
> output, so I preferred doing that myself to avoid one more layer of complexity /
> bugs / whatever.

Sorry for jumping into the discussion so late, but: By duplicating the code in
GPGME you are not avoiding the bugs, you are just making them yourselves.  But
now you can't benefit from our fixes in GPGME (and we can't benefit from yours).

GPGME isn't the answer to all needs, but it should provide a useful basis for
any further enhancements to the API you can think of.

> So, being both --with-colons and the keyring format uncertain, why adding one
> more layer (i.e. forking the gpg process from my current code, read its output,
> act consequently) to the code, if I can directly read the keyrings?

Layers are good.  They protect what's inside from the outside, and the other
way round.

> The conclusion is: if it's too difficult, or does not give concrete advantages
> over the method I'm using now, then all the argumentation above is moot. But,
> if it gives concrete advantages (in terms of speed, for example), it might be
> worth a try, at least. Or, an option could be giving developers the chance to
> use whichever implementation they prefer/trust.

GPGME has almost no overhead.  Starting the gpg process has some significant
overhead, but it's unavoidable.  For gpgsm we already have experimental code
to only do this only once per gpgme context, for many operations, in which
case it is amortized easily.  In the future, we want to do the same for gpg.
By using gpgme, you can automatically benefit from such improvements.

Thanks,
Marcus