GSoC project idea

[Doron Behar]

On Mon, Mar 18, 2019 at 04:49:11PM +0100, Dashamir Hoxha wrote:
> On Mon, Mar 18, 2019 at 4:07 PM Doron Behar <doron.behar at gmail.com> wrote:
> 
> >
> > 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.
> >
> 
> 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.
> 
> 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.

I agree but say that building a single executable that will accept both
CLI syntaxes won't be easy to implement, even submitting a patch to the
mainstream code with the additional `ipg` executable would be a good as
well right?

> 
> 
> >
> > > 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.
> >
> 
> 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.
> 
> > 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.
> >
> 
> 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.

I just wanted to notify you that today I've found out that I won't be
able to submit this project to the next GSOC since I'm not a student yet
and therefor I don't have a proof of enrollment. I wonder whether I can
register as a mentor without being a student, if so it's probably not
possible only yet.

> 
> Dashamir

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