If that is the goal, that is a fair one. Thanks, Bob Cavanaugh
> -----Original Message----- > From: Hans-Christoph Steiner [mailto:h...@guardianproject.info] > Sent: Monday, March 09, 2015 2:22 PM > To: Bob (Robert) Cavanaugh; Peter Lebbing > Cc: gnupg > Subject: Re: Thoughts on GnuPG and automation > > > I expect a discussion about what is working and what is not working with > GPGME and various GnuPG APIs. I'm just trying to convey my experience > with GnuPG-for-Android, gnupg-for-java, and a little bit with Python. I hope > this will spur people to offer their experience, and generate new ideas and > approaches. gpgme-tool is one version of that, `gpg --json` is another. > > .hc > > Bob (Robert) Cavanaugh: > > Hi Hans, > > Wanted to respond to your post wondering why you are getting the > responses you are. > > > > In another thread you write: > > "There are other C-Python wrappers of GPGME, like pyme. I hope you're > aware of those, and have studied them. One thing that GnuPG suffers from > is many people starting their own wrappers, but few people finishing them > or contributing to existing ones. That is not a sustainable situation." > > > > This is the problem. You frame the dialog as blaming GnuPG and the > > design choices made in its implementation. Direct case in point: It is > > certainly not Werner's or any other principal GnuPG developer's issue > > if and when someone else independently took on a project to wrap GnuPG > > or GPGME. The fact that these people might have bitten off more than > > they can chew is completely irrelevant to the canonical implementation > > and frankly should be irrelevant to this discussion. When I said > > approach this in a constructive manner I meant this: You have some > > requirements. In your estimation these requirements are not met with > > the current toolset. Then instead of explicitly expecting this group > > to implement a paradigm shift (and forgive me if I misunderstand you, > > but that is what I infer you are asking for) generate a proposal for > > an Android-centric API. Or, if you feel that the infrastructure cannot > > support it, take the completely open sources Werner and group have > > provided and generate your ow > n > system that meets your needs. If possible, (and here again I am clarifying > my original post) work with the people on this group to help you use the > existing tools to get your requirements met. But speaking as a professional > engineer of 25+ years experience, you will not get your desired results by > starting the conversation impuning the work that went before and claiming > that what you are asking for is far superior. If it is not your intent to > convey > that message then please review what you write before you send it, because > that message was received loud and clear. > > > > Thanks, > > > > Bob Cavanaugh > > > > > >> -----Original Message----- > >> From: Hans-Christoph Steiner [mailto:h...@guardianproject.info] > >> Sent: Monday, March 09, 2015 12:08 PM > >> To: Bob (Robert) Cavanaugh; Peter Lebbing > >> Cc: gnupg > >> Subject: Re: Thoughts on GnuPG and automation > >> > >> > >> Why do I get so many responses like this on this list? I've spent a > >> ton of time solving our own problems with the Android port, we also > >> made sure to take out a support contract with Werner to pay him to > >> answer our questions. I only wish we'd had more so we could pay him > >> for all the work he has done, but we have long since run out of money > >> for working on GnuPG. I continue this on my own time because I believe > it is important. > >> > >> The point of this discussion is to talk about an shared architecture > >> for using GnuPG outside of C/C++ on UNIX. That's why Bjarni started > >> it, and that's why I've joined in here. It seems that half of this > >> thread has been griping about the discussion process. We need a > >> little more faith in each other so we can have productive discussions and > further our shared goals. > >> > >> .hc > >> > >> Bob (Robert) Cavanaugh: > >>> 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 > >>> > >> > >> -- > >> PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 > >> > https://pgp.mit.edu/pks/lookup?op=vindex&search=0x9F0FE587374BBE81 > > -- > PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 > https://pgp.mit.edu/pks/lookup?op=vindex&search=0x9F0FE587374BBE81 _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
