<div dir="ltr">Hi,<div><br></div><div>A couple of years ago I was suggested that using GPGME</div><div>for implementing EasyGnuPG would be better than using</div><div>the command `gpg` directly. And indeed I thought that it was</div><div>a good idea, but I couldn't give it a try because I didn't know</div><div>Python and I had no more free time left.</div><div><br></div><div>A couple of months ago I started a GSoC project about this,</div><div>and now it is almost finished. You can see the changes here:</div><div><a href="https://github.com/EasyGnuPG/pgpg/pull/84/files?utf8=%E2%9C%93&diff=unified&w=1">https://github.com/EasyGnuPG/pgpg/pull/84/files?utf8=%E2%9C%93&diff=unified&w=1</a><br></div><div>(green lines are the original code, and red lines are the new</div><div>code which replaces the command `gpg` with Python code</div><div>and GPGME, it is a reverse diff).</div><div><br></div><div>Now that I look at it, I think that the original code is better,</div><div>and it is not worth replacing `gpg` by GPGME calls.</div><div>However I would like to know your opinion as well.</div><div><br></div><div>The reasons that I think so are these:</div><div><br></div><div>- `gpg` calls are more compact than the corresponding GPGME code.</div><div>   Basically we are replacing a single line of Bash code with about</div><div>   20-30 lines of Python code. It can expand even further if all the edge</div><div>   cases are handled properly (right now they are not handled).</div><div>   In my opinion this increases the complexity of the code, makes it more</div><div>   difficult to understand and maintain, and is unnecessary.</div><div><br></div><div>- Not everything that can be done by the command `gpg` can be</div><div>  achieved through GPGME. So, we still have to rely on `gpg`</div><div>  for some parts of the program. See:</div><div>  <a href="https://lists.gnupg.org/pipermail/gnupg-devel/2018-July/033829.html">https://lists.gnupg.org/pipermail/gnupg-devel/2018-July/033829.html</a></div><div><br></div><div>- Even those things that can be achieved by GPGME are not done</div><div>  easier than doing them from `gpg`. For example those actions</div><div>  that need interactivity. My hope was that there would be a better</div><div>  way for doing them in GPGME, but I was disappointed. Either there</div><div>  is no better way, or there is no way at all.</div><div><br></div><div>- One of the advantages of using GPGME would be that the programmer</div><div>   has better control over the output. Since `gpg` output is meant for the</div><div>   humans, it is difficult to be parsed by the programs, and it is difficult to</div><div>   customize. With GPGME we have better control over the output.</div><div>   </div><div>   However the aim of `egpg` has never been to replace `gpg`, but</div><div>   to make it easier for the users. One of the design goals of `egpg`</div><div>   is that it tries to integrate seamlessly with `gpg`, so that the users</div><div>   can switch to `gpg` easily if they find that the assumptions and</div><div>   the simplified interface of `egpg` restricts them somehow.</div><div>   So, displaying the original messages from `gpg` in this case</div><div>   is actually a god thing, not a bad thing, since it helps the users</div><div>   to get familiar with the `gpg` itself, although they are using `egpg`.</div><div><br></div><div>In general, I find GPGME an incomplete programming interface (API).</div><div>For some applications it may be sufficient, but there are certainly cases</div><div>that it cannot handle. I think that GPGME may become complete only</div><div>when the `gpg` command itself is built on top of it.</div><div><br></div><div>I also find odd and not quite suitable for programming the interactive</div><div>interface. It could have been better if GPGME used a RESTful API</div><div>for communicating with the GnuPG engine (similar to what most</div><div>of the web services use nowadays). For example GPGME can send</div><div>to the server (GnuPG engine in this case) an action and the parameters </div><div>(the data) needed to perform this action, and then get an answer with</div><div>a status of the result, the result itself, any error messages, etc.</div><div><br></div><div>The GPGME (or at least the Python implementation) can also build</div><div>and present to the applications a higher level of abstraction, for example</div><div>an object-oriented representation of the data and the actions performed</div><div>on them. This could make easier to build applications that are based</div><div>on GPGME.</div><div><br></div><div>However all these changes for improving GPGME maybe need</div><div>another GSoC project, or a project wider than that.</div><div><br></div><div>On the other hand, the `gpg` command itself can try to make easier</div><div>the life of programmers by:</div><div>1 - Trying to offer a batch mode for any action that currently can be done</div><div>      only through interactivity.</div><div>2 - Trying to offer a more programmer friendly output. One of the</div><div>      problems with trying to call `gpg` directly on applications is that</div><div>      its output is meant for humans, so it is difficult to be parsed by</div><div>      applications. However the situation would be better if there was</div><div>      an option or an environment variable to tell it to output programming</div><div>      friendly output instead. The format of this output can be JSON,</div><div>      or XML, or whatever can be parsed easily by the applications.</div><div>      It may also be configurable.</div><div><br></div><div>Implementing these improvements to `gpg` seems to be a big project</div><div>as well, and it may also be interwoven with the project of improving</div><div>GPGME.</div><div><br></div><div>These are my thoughts about building GnuPG based applications.</div><div>Any opinions would be welcome, especially from other people who</div><div>have used or are trying to use GPGME on their applications.</div><div><br></div><div>Regards,</div><div>Dashamir</div><div><br></div><div><br></div></div>