gpgme_data_seek with SEEK_END on memory-based data fails

[Werner Koch]

On Tue, 21 Aug 2012 00:41, ekleog at gmail.com said:

> Yes. But concentrating the charge of all "my" users on a single server isn't
> very good, and at my house round-robin DNS such as keys.gnupg.net have a really
> long response time, while e.g. pgp.mit.edu is really fast.

The problem here is that we have the external keyserver helpers which
are stateless.  They need to do the DNS queries again and again.  With
2.1 this will go a way because the dirmngr takes care of keyserver
access and is able to maintain a list of responsive keyservers from a
round-robin address.

> We already have GPGME_KEYLIST_MODE_EXTERN, which specifies from where to look
> for the keys. This could also be considered as a GnuPG implementation detail.

No where to look for the keys but to do an external lookup.  External
lookups have different properties:  They may take long, they may return
inconsistent results over time, and they have privacy implications.
The initial reason for having such a flag is for X.509 LDAP lookups

We try to GPGME's API protocol neutral: One API for all protocols.
Keyservers are very OpenPGP specific.

> But setting the keyserver is almost as useful : it allows to use a local
> keyserver, or to use some keyserver not synchronizing with the others
> (keyserver.pgp.net ?), etc.

Now, why to you want to change it with every operation?  I still
consider it a configuration option and not a property of a concrete
operation.

> As a last statement, I believe (but that's only my humble opinion) that GPGME
> should offer as much options as GPG does, so that one doesn't have to hesitate
> between parsing GPG's output (developper-time-consuming, error-prone),

GPG has way too many options.  GPGME allows to access a subset of the
configuration options using its configuration API.  If there is a useful
runtime option, we can consider to add it to GPGME.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.