[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNUnet-developers] A few comments and fixes to the documentation

From: ng0
Subject: Re: [GNUnet-developers] A few comments and fixes to the documentation
Date: Sat, 6 Jan 2018 19:03:49 +0000

Amirouche Boubekki transcribed 3.1K bytes:
> On 2018-01-06 09:00, ng0 wrote:
> > Amirouche Boubekki transcribed 10K bytes:
> > > You must not commit that as is. As it was meant to start a discussion.
> > > 
> > 
> > If you want to send a patch that can be applied to git,
> > remove this from the patch:
> > 
> > address@hidden FIXME: is it clear to the average reader what a 
> > man-in-the-middle
> > address@hidden attack is?
> > 
> > and I can address the rest in a follow-up patch.
> > 
> > Good additional comments btw, I haven't worked much on the developer
> > chapter.
> > I'll try to answer them next week.
> > The state of the content of the developer chapter is still mostly the
> > import from Drupal, so fixes are more than welcome!
> I am not sure I will be able to proof read more of the documentation,
> because I started to rewrite the guile bindings.

Okay, no problem. I'll just apply the changes you suggested then.

> Actually there is not much in the current gnunet-guile, so it's still

Yeah, it was a GSoC project and for that, reading the past discussions,
much happened in the short time.. I guess.

> a win to restart from scratch. This is an opportunity to introduce
> the use of guile-bytestructures which helps a lot to build structs and
> unions.
> The new code is less confusion with less macrology and less code in general,
> it's my code afterall ;)

Cool. Do you want push access to that repo or a new one on
if that's more convinient for you? You'd just have to send an ssh key
(ideally gpg signed and encrypted), the access would be just for the
one repo.

> I already have a sketch of gnunet-downloader which works.

Superb :) I didn't expect any of this to happen. So good :)

> My plan is to create an alternative to gnunet-foo commands using the
> guile bindings. What would be a good name of that command, e.g.
> gnunet-guile?

What do you mean? Well, gnunet-guile could just be completely rewritten.
If you mean a binary/script name that launches other scripts, yes gnunet-guile
could work out. But you could name it smesh or anything, as long as it makes
sense and isn't too long to write.
Details.. I mean names can be fixed up later.

> A problem, I have no solution for right now, is testing the bindings.
> Unittesting doesn't make sens, since the bindings requires gnunet-arm
> and the services to be running. Help will be appreciated in this
> regard.

I think Grothoff or any other dev could answer most of these questions
technically more correct than I would be able to at this point. I could
explain it, but I want to avoid causing confusion.

> My take away, after hacking 12 hours on the bindings and reading the doc
> from my perspective, correct me if I am wrong:
> - They are three kinds of programs in gnunet:
>   - daemons, I am not sure what they are. Help?
>   - service, expose an API over IPC which daemons
>     and ui can query. My understanding is that those
>     are started via the gnunet-arm, the principal daemon.
>   - ui, those are gnunet-gtk, gnunet-download, gnunet-publish, etc.
>     Those are client programs of gnunet services.
> - As a matter of fact, there is already various example use of the
>   API (over IPC) provided by the different services because there
>   is command line programs for most if not all the parts of gnunet.
> - Everything happens over IPC. Basically, IPC is like REST instead of JSON
>   it use C structs with unions and instead of HTTP is use (raw) sockets.
> - I don't need to write the client library myself. Since communication
>   inside gnunet happens over IPC, the client library is already part of
>   gnunet.
> - That said, to use the provided client libraries, you will need to
>   use gnunet scheduler (see gnunet_scheduler_lib.h part of
> - Also, you can implement a driver for the scheduler to integrate it
>   with another event loop (maybe that's what is done in gnunet-gtk).
> - The client API is asynchronous using callbacks.
> Also, we need to discuss guix integration at some point, but like I said
> earlier I aim for generic bindings of gnunet not something specific to
> guix.

The last part is exactly what the earlier version of gnunet-guile / guile-gnunet
was working towards to, and what my primary interest in the long run is for
Somehow I ended up starting to design a templating language/framework "thing"
(early stages, design) to make non-Guile using configuration of Guix possible
as an underlying core-element of infotropique OS to serve as a base for GNUnet
applications to be shipped out.. long, complicated story, more on that soon.
Long story short: Yes, absolutely. Yes! I've come up with some ideas beyond
the original designs, but at this moment I don't have any strong opinions about
the implementation. Discussion is good and discussion fell asleep for 3 years
within Guix on this topic. happy to collaborate :)

> ~ amz3
> _______________________________________________
> GNUnet-developers mailing list
> address@hidden

GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588
  WWW:  ::

Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]