Thoughts on GnuPG and automation
Bob (Robert) Cavanaugh
robertc at broadcom.com
Wed Mar 4 01:43:29 CET 2015
Native to what? Processor, OS?
I think Peter and the group already adequately answered this: If GPGME is not providing an interface that meets Android requirements, then look into how GPGME interfaces to GPG and emulate that interface.
For you to request that the interface be changed can be likened to someone requesting that I2C be changed because you have a hard time implementing it. This is pretty much a non-starter IMHO. Implementing interfaces to existing infrastructures is bread-and-butter to software development. Stop asking for fundamental infrastructure changes and start solving your problem. The group has literally hundreds of m-y that can be used productively to help you do this, but harness the group's power in a constructive manner.
From: Gnupg-users [mailto:gnupg-users-bounces at gnupg.org] On Behalf Of Hans of Guardian
Sent: Tuesday, March 03, 2015 3:55 PM
To: Peter Lebbing
Subject: Re: Thoughts on GnuPG and automation
On Mar 3, 2015, at 7:09 PM, Peter Lebbing wrote:
In Android, you can't really have shared libraries. Apps share functionality at a higher level (aka Activities and Services). So GnuPG-for-Android _is_ the shared library in effect, since it provides OpenPGP via Activities.
No one is saying that each app should have a custom wrapper for GnuPG. What I think mailpile is saying, and what I'm trying to say is that for programming environments where GPGME does not make sense, there should be the ability to easily make a native version of what GPGME is doing.
Gnupg-users mailing list
Gnupg-users at gnupg.org
More information about the Gnupg-users