Bernd's comments on GPGME

[Marcus Brinkmann]

On Mon, Jul 21, 2003 at 02:25:55PM -0500, Robert J. Hansen wrote:
> My biggest concerns with GPGME are:
> 
>       * API flux--look at how many functions from 0.3.x are deprecated
>         in 0.4.x

This criticism is of course justified: GPGME 0.4.x is a radical departure
from 0.3.x as far as the API is concerned.  There are two reasons behind it,
and maybe they help to understand why 0.4.1 was necessary.  The first reason
is that many APIs in GPGME 0.3.15 where remarkably similar to how they were
in the very early versions of GPGME.  Some of these functions and structures
have been added in the very beginning carelessly, and were neither fitted to
the applications requiring them, nor where they designed to allow for future
extension.  Since then, we have learned a lot about how the API should look
like, so we took the chance and fixed a lot of these first-cut problems.

One of the worst problems in GPGME 0.3.x was that the result of an operation
could often not be fully examined easily.  The error reporting was not very
detailed, and the result was sometimes only available in XML texts.  This
has caused a series of small API changes in GPGME 0.3.x, and required many
applications to have additional code to parse XML texts etc, which was
copied from one program to others (a good sign that your library does not do
its job properly).  So what we have done is that we designed a framework
where errors from any part of the GPG system can be passed through
transparently, and we also made all the GPGME functions return detailed
structures about the result of an operation - something that can be extended
later without braking API or ABI.  At that stage it was also desirable and
feasible to make the interface consistent.

The bottom line is that none of these changes were deliberate, and that they
all are carefully done to avoid future changes from now on, and prepare
GPGME for 1.0 - the time where no API or even ABI changes are allowed anymore.

>       * Glacial pace of development--I released Codebook 0.3.2 on July
>         4, 2002, using GPGME 0.3.x (x = 10, I think).  One year later,
>         the stable version is 0.3.x (x = 15) and the bleeding-edge is
>         0.4.1.

Well, what can I say.  I think we have done quite some progress, especially
with the internals of GPGME.  Using it in multi-threaded or event-loop based
environments, using transparently OpenPGP or CMS, and key signatures are
some of the new core features, and more are planned.  Not sure how much a
version number is worth, if it helps I could name the next version 0.8 ;)

>       * The closed nature of its development.  While GPGME is free
>         software, my attempts at volunteering to help out with its
>         development to try and speed it up some have mostly been met
>         with "we're trying to keep it all in-house".

Beside its authors, 10 people and more have contributed to GPGME according
to the THANKS file.  If you want to help, then the best way to do this is to
explain what you try to do, and then make specific suggestions what to change
how.  A patch would be wonderful, but we require copyright assignments for
signifcant code contributions.

One problem is certainly that not much of the design is done visibly.  This
is just because that it is done mostly in my head and thus no communication
is strictly required.  What I mean is that nothing is hidden from you that
is easily available.  The best way to fix this is for you to challenge us -
ie, if you have questions about why some things in GPGME are the way they
are, or why we don't do it in some specific other way, just ask.

It would be just great if we had so much technical discussion about GPGME
on gnupg-devel that we need our own list!  But that requires everybody of you.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    marcus at gnu.org
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
Marcus.Brinkmann at ruhr-uni-bochum.de
http://www.marcus-brinkmann.de/