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.
Bob Cavanaugh -----Original Message----- From: Gnupg-users [mailto:gnupg-users-boun...@gnupg.org] On Behalf Of Hans of Guardian Sent: Tuesday, March 03, 2015 3:55 PM To: Peter Lebbing Cc: gnupg 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. .hc _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
