<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 19, 2019 at 12:53 PM Bernhard Reiter <<a href="mailto:bernhard@intevation.de">bernhard@intevation.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
The main problems I see with the idea:<br>
a) How long and by whom would this wrapper be maintained?<br>
   It is hard enough to maintain the current gpg as it is.<br>
   If the perspective is only up to three years, then we cannot really<br>
   recommand anyone to learn the new interface as it is likely to go away<br>
   after that time and the original gpg will stay. It would be just for<br>
   experimentation.<br></blockquote><div><br></div><div>Is it more acceptable to submit a patch that adds the new functionality, rather than building a wrapper? Of course you don't have to accept it unless it is done properly.</div><div>I think that experimentation is worthy too. A wrapper might be easier and more flexible if we want to experiment just to get a better feeling about the new interface. However Donor has already started working on the C code and it might be a bit easier to just continue in that direction.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
b) There are many better ideas how to help end to end encryption with GnuPG<br>
   to provide a better user experience. For example implementing automatic<br>
   encryption after a WKD request in more email clients. Writing instructions<br>
   how to set up simple WKD on the server.<br></blockquote><div><br></div><div>I agree but I don't have any idea about how to recruit new developers for these tasks.</div><div>By the way, Google Season of Docs is around the corner: <a href="https://developers.google.com/season-of-docs/">https://developers.google.com/season-of-docs/</a></div><div>Maybe this can be a good opportunity to improve the docs (about WKD etc.) The best part of GSoD is that it is not limited to the students, so hopefully the quality of the resulting work will be better.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> I think this is suitable task for a GSoC project that can be developed in<br>
> 2-3 months by a good student, with help and guidance from mentors.<br>
<br>
If it would be clear what each option would do, the implementation time would <br>
be enough, but the assumptions of the current interactive command line <br>
interface and all its bells and whistles are many and interact in a complex <br>
way, so to me it is doubtful that a student can handle this in 3 months. <br></blockquote><div><br></div><div>That's why the mentors are needed. This may also be a good reason for considering the new interface as experimental, which may initially change frequently.</div><div><br></div><div>Best regards,</div><div>Dashamir</div><div><br></div></div></div>