aborting (or finishing) pending operations in GPGME

[Marcus Brinkmann]

Hi,

the new gpgme_op_keylist_end() function is not the last word on terminating
pending operations in GPGME.  It might be desirable to remove it in the next
version in favour of a more generic function that can terminate any
operation, or something completely different, but here is the whole story:

We have two classes of operations in GPGME, operations that are naturally
split into _start and _end counterparts, because the usual mode of operation
is to call something inbetween, like _next.  The two examples are keylist
and trustlist.  Note that a trustlist operation currently has the same
problem as keylist had before we added keylist_end.

The other class contains operations which only use callback functions, and
don't have a need for intermediate calls between starting the operation and
ending it.  This is what decrypt etc belong to.  They are usually invoked as
op_foobar rather than op_foobar_start + something.

The reason for this is apparently that it is more convenient to get the
keys and trust items on demand rather than automatic through a callback, and
that the other functions are more conveniently used via callbacks because
here the feeling is more like data that is being pushed from the engine to
the user.  (I say feeling, because technically there is no difference. 
keylist and trustlist could be implemented via callbacks just as well).

However, the gpgme_op_foobar_start form of the operations in the second class
is quite unusable.  The gpgme.h header describes the gpgme_op_foobar as
convenient functions, but they are a necessity, because gpgme_op_foobar
can't be implemented using the _start form and just the public interface of
gpgme.  There are two reasons for that:

1. The pending flag is never reset and not resettable.
2. The resulting error value of the operation is not calculable via the
   public interface.  It is retrieved through internal interfaces.

It is now the question how much flexibility and what semantics application
programmers desire.  Several strategies are thinkable, for example one could
just remove the _start functions for class 2 operations from the public
interface, because they serve no value I can think of.  The only thing you
can ever do after that is call gpgme_wait() on the context, and then you
could delay starting the operation to the time you are going to do that.
Am I missing a reason for the potential asynchronous usage here?

So, what do you need to write the best crypto-enabled applications possible?

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de