GPAPA Interface Design Musings

[Bernhard Herzog]

The documentation of GPAPA is pretty scarce (well, there doesn't seem to
be any :| ), and I've got a couple of questions and suggestions for
future development. The document I'd need most is an overview of the
design of GPA. Some of the things I mention below may have been
addressed by gpgme, but there doesn't seem to be any overview for it
either (especially interesting for gpgme would be to know what is
different between it and gpapa).

All this is purely from the point of view of a user of gpapa. It doesn't
deal with gpapa internals at all.


1. Memory Management
--------------------

One of the main questions in any C library is who own the memory that
pointers point to, or in other words who is responsible for freeing it
and other resources. Another is how long pointers that are borrowed form
the library (i.e. where the library is responsible for freeing them)
stay valid.

As I understand it, GPAPA maintains a list of keys and most functions
that retrieve keys return a pointer managed by those lists. That means
that the caller is not responsible for freeing them.

That still leaves the question of how long the key pointers are valid.
It would be very convenient for the GUI if I could store the key
pointers as "user_data" in the rows of a GtkCList, for instance. That's
probably not possible because if gpapa is the sole owner of the keys
they might be deallocated at any time. For the time being I store the
key id's as "user_data" which works quite well.


2. Error Reporting
------------------

Gpapa uses a callback to report errors to the caller. This is not
necessarily bad, but unfortunately there's no easy way to tell whether a
function call failed or not after it completes. Two solutions would be
to either use global variables for this (which is a bad use for global
variables IMO) or to use the calldata argument. The latter is awkward
because there already is a calldata parameter commonly used in GPA (The
window to use as a parent for the error message box) so we'd have to
pass a pointer to a struct (or something similar) and setting that up in
every function that calls a gpapa function is tedious.

It would be better if the gpapa functions had a return value that at
least indicates whether the function succeeded or not. Showing error
messages to the user could still be handled through the callback.

This part seems to be fixed in gpgme.


3. Updating the GUI
-------------------

After a gpapa function completes that modifies the keyrings, trust
databases etc., the GUI has to be updated. One way to do that is for the
GUI to call the appropriate functions at the right times (e.g. update
the keylist after a keypair has been generated), but that becomes quite
error prone when the GUI becomes more complicated or when it changes
frequently because it's easy to forget to insert calls to update newly
added widgets because the places where you ahve to insert them are
scattered all over the place.

Another problem with the way some of the updates are handled in GPA
currently is that parts of the GUI code make assumptions about what will
change. For instance, the "key delete" function simply deletes the
appropriate row from the CList widget after the gpapa call. Such things
are dangerous because that way the GUI depends on how things work in the
underlying implementation. It effectively duplicates program logic which
is always a maintenance problem.

IMO, the best solution to all this is to use some form of the
Model/View/Controller architecture. In that architecture gpapa would be
the model and the GUI widgets would be view and controller. The
controller part takes user input and calls the appropriate model (gpapa)
functions. The model then informs the views that something has changed
and the views can update themselves.

The important bit is that the model does not have to know how many views
there are and what parts of the model they display and the controller
doesn't have to know about the views or the models internal logic. That
ensures that all necessary GUI updates happen and that the program logic
is in only one place, the model (which in GPA may mean gpapa and gpg).

It's too late to introduce that to gpapa, although I think it would be
nice to have in gpgme, assuming it isn't already supported in gpgme.


  Bernhard

-- 
Intevation GmbH                                 http://intevation.de/
Sketch                                 http://sketch.sourceforge.net/
MapIt!                                               http://mapit.de/