GSoC project idea

[Doron Behar]

On Mon, Mar 18, 2019 at 01:31:23PM +0100, Dashamir Hoxha wrote:
> On Mon, Mar 18, 2019 at 12:21 PM Doron Behar <doron.behar at gmail.com> wrote:
> 
> > Hello Dashamir,
> >
> > Thanks for showing your interest in this idea. I thought more about it
> > after I've sent the email to the mailing list and I reached the
> > conclusion that it might be more efficient to _fork_ the existing
> > code-base and use the same existing functions and only bind them to a
> > different executable that will have a different use of argparse.
> >
> 
> Do you preserve the existing commands and options of `gpg`, for backwards
> compatibility? If yes, maybe there is some chance that your changes will be
> merged some day to the main project. Otherwise I think that it is going
> nowhere. Neither the developers nor the users will accept radical changes
> to the CLI of `gpg`. I don't think your aim is to maintain it forever as an
> alternative to `gpg` because this is a huge task.

In my fork I didn't modify anything, only added. The idea is to add only
a directory named ipg (Acronym for improved privacy guard) and in it all
the code that will use the functions that already exist in the source
tree; So when a user builds my version from the git source (autoreconf
&& ./configure && make && make install), he will a get another
executable installed called `ipg` that will be equivalent to `gpg` in
it's use but will have a nicer CLI syntax.

Both executables (gpg & ipg) installed by my version will be equally
updated to use the latest version of the C code that implements the
actual encryption and decryption etc.

> 
> 
> > Actually, I've already created a prototype of this and the missing work
> > to be done is connecting everything to the already existing functions
> > available in the code-base.
> >
> 
> It does not seem so easy to me because you may need some feedback from more
> experienced people, although you may think that you have organized the
> commands and their options properly.

I think the only difficult part in this design (and please correct me if
you think I'm wrong) is making sure that when the upstream source is
updated and functions change their names etc., my fork updates the names
of the functions it calls.

Also, according to my design, almost every sub-command and it's optional
flags have their equivalent in the current syntax, strictly according to
the documentation. The only difference is that some sub-commands
naturally don't accept all options that may be accepted (but ignored!)
in the current syntax. Most importantly, this should also prove to be
more comfortable for shell completions to not overwhelm users with
options most of which are irrelevant for the current _action_ they want
to perform.

> 
> 
> >
> > It is indeed a good project for a student. Only I'm not sure I'll be
> > able to do it myself, although my motivation is rather high. I'm
> > preparing myself for the 1st year of Computer Science studies in
> > university these days so I don't have a lot of spare time.
> >
> 
> You can be one of the mentors, which hopefully should not be very time
> consuming.

As a mentor, am I not obliged to be an experienced C programmer? If so,
that could be an excellent idea.

> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel