Re: Pre-announcement of partial Scheme port of client libraries

[Maxime Devos]

Christian Grothoff schreef op wo 15-09-2021 om 16:12 [+0200]:
> On 9/15/21 12:57 PM, Maxime Devos wrote:
> > Hi,
> > 
> > I've been porting parts of the client libraries of GNUnet to Guile (*) and
> > changing a few things.  It now has sufficient functionality for a v0.1
> > POC release (**), but I have a few questions to ask before I announce it.
> 
> Nice.
> 
> > (*) See ‘4. Relation to gnunet-guile’ for differences with
> > <https://git.gnunet.org/gnunet-guile2.git/> and
> > <https://git.savannah.gnu.org/cgit/guix/gnunet.git/>;;.
> > (**) It can talk with the NSE service.
> > 
> > 1. Name
> > 
> >    I've been calling the port ‘Scheme-GNUnet’.  Would this be acceptable,
> >    or do I have to remove GNUnet from the name?
> 
> See https://git.gnunet.org/: usually we'd call it gnunet-scheme. At
> least that'd be consistent with the cocoa, go, nim, java and python
> bindings / integrations...

Right.  I think I'll rename it to gnunet-scheme or gnunet-guile.  The latter
might cause confusion with <https://git.gnunet.org/gnunet-guile2.git> though
...

> > 2. Infrastructure
> > 
> >    As it is library for interacting with GNUnet services, I thought
> >    the pre-existing gnunet-developers@gnu.org, help-gnunet@gnu.org and
> >    info-gnunet@gnu.org mailing lists might be appropriate.  Can I direct
> >    people help-gnunet@ for help about Scheme-GNUnet and gnunet-developers@
> >    for sending patches for Scheme-GNUnet?  And can I send release 
> > announcements
> >    at info-gnunet@?
> 
> Yes, alas I might need to manually approve info-gnunet@ (ditto for
> messages from non-subscribers), so they might arrive with some delay.

Messages to info-gnunet@ will be relatively infrequent, so that shouldn't
be a problem.

> > 3. Copyright assignment
> > 
> >    I noticed most source code of GNUnet, with some exceptions, only lists
> >    ‘GNUnet e.V.’ under the copyright notices.  Would it be possible for
> >    contributors to Scheme-GNUnet to (if they want to) assign the copyright
> >    to GNUnet e.V.?  And would this be desirable?
> 
> Yes, that would be desirable (also for your contributions), as that
> could allow GNUnet e.V. to re-license/dual-license if ever required.
> Note that the process is very simple (one signature), can be done under
> a pseudonym (if you contribute under a pseudonym), and you also get to
> keep the copyright! See https://gnunet.org/en/copyright.html for details.

I don't have access to a printer at the moment, so this will have to wait
a little.

> As a rule of thumb, if you want write-access to git.gnunet.org, you must
> sign the copyright agreement (technically what we do is not an
> _assignment_ but _sharing_ of the copyright).

FWIW, the title of ‘copyright.pdf’ is ‘Copyright Assignment Agreement for
Contributors to GNUnet’.

> > 4. Relation to gnunet-guile (not a question).
> > 
> > Some may be wondering why I didn't use the
> > <https://git.savannah.gnu.org/cgit/guix/gnunet.git/> or
> > <https://git.gnunet.org/gnunet-guile2.git> Guile bindings instead of writing
> > my own <https://notabug.org/maximed/scheme-gnunet>;;.  The answer is that:
> > 
> >    (1) I didn't write Guile->C bindings, I ported parts of GNUnet from C to
> >        Guile
> >    (2) A few parts of the Guile bindings are reused in the Guile port
> >    (3) there were some crashes with the Guile bindings (things like
> >        NULL-pointer exceptions)
> >    (4) I couldn't figure out the issue
> >    (5) I would like to use GNUnet from within guile-fibers, but didn't 
> > succeed
> >        in letting the C event loop cooperate with guile-fibers' scheduling
> >    (6) I find Scheme easier to hack on than C.
> 
> I think that's a fine (and maybe generally preferable) approach rather
> than doing bindings. I'd just not do the crypto itself directly in
> Guile, that's likely neither performant nor safe.

Bindings for crypto libraries already exist and appear to work well
and easy to use.  E.g. guile-gcrypt has been succesfully used in Guix
and nettle's C API seems trivial to wrap.  The pure crypto (I'm including
hashing here) will be done by a wrapped C library.

>  The real question is,
> does your work render the bindings obsolete?

At the moment, not yet, because it doesn't support GNS, DHT, FS ...
But eventually, I think it will.

> > For the interested, I have included a copy of the manual.
> 
> Very nice ;-).
> 
> Happy hacking!

Greeting,
Maxime.

signature.asc
Description: This is a digitally signed message part