<div dir="ltr"><div dir="ltr">On Mon, Mar 18, 2019 at 4:07 PM Doron Behar <<a href="mailto:doron.behar@gmail.com">doron.behar@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
In my fork I didn't modify anything, only added. The idea is to add only<br>
a directory named ipg (Acronym for improved privacy guard) and in it all<br>
the code that will use the functions that already exist in the source<br>
tree; So when a user builds my version from the git source (autoreconf<br>
&& ./configure && make && make install), he will a get another<br>
executable installed called `ipg` that will be equivalent to `gpg` in<br>
it's use but will have a nicer CLI syntax.<br>
<br>
Both executables (gpg & ipg) installed by my version will be equally<br>
updated to use the latest version of the C code that implements the<br>
actual encryption and decryption etc.<br></blockquote><div><br></div><div>In my opinion, it might be better if there was a single executable (gpg) that can accept both sets of CLI commands. If this is possible.</div><div><br></div><div>In any case, I think that the aim should be to finally submit a patch to the mainstream code, and hopefully it gets accepted. Distributing it separately as an improved version of gpg is not going to work for many reasons.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
> It does not seem so easy to me because you may need some feedback from more<br>
> experienced people, although you may think that you have organized the<br>
> commands and their options properly.<br>
<br>
I think the only difficult part in this design (and please correct me if<br>
you think I'm wrong) is making sure that when the upstream source is<br>
updated and functions change their names etc., my fork updates the names<br>
of the functions it calls.<br>
<br>
Also, according to my design, almost every sub-command and it's optional<br>
flags have their equivalent in the current syntax, strictly according to<br>
the documentation. The only difference is that some sub-commands<br>
naturally don't accept all options that may be accepted (but ignored!)<br>
in the current syntax. Most importantly, this should also prove to be<br>
more comfortable for shell completions to not overwhelm users with<br>
options most of which are irrelevant for the current _action_ they want<br>
to perform.<br></blockquote><div><br></div><div>I understand your design and its advantages, but I am not sure wheather you understand all the details about `gpg` commands and options. Maybe you do, myself I don't.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> You can be one of the mentors, which hopefully should not be very time<br>
> consuming.<br>
<br>
As a mentor, am I not obliged to be an experienced C programmer? If so,<br>
that could be an excellent idea.<br></blockquote><div><br></div><div>If you are an experienced C programmer that's great. But you don't have to be. You can also be an experienced `gpg` user. And anyway, the idea of reorganizing the commands is yours and you know what you are aiming for better than anyone. So, you can definitely be one of the mentors, if you have time and if you want to be.</div><div><br></div><div>Dashamir </div></div></div>