Re: [GNUnet-developers] GSoC: Binary package distribution through GnuNet (report 1)

[Ludovic Courtès]

Hi!

address@hidden skribis:

> This first week started with cleaning and organizing the draft
> bindings I’ve been working on previously (set up of a proper directory
> structure, a small Makefile, etc.), then most of the work has been on
> mapping GnuNet’s data structures.
>
> This week, I’m heading for the remaining “most-needed” functions (URI
> handling, scheduling) and some testing, and also writing a simplified
> version of the `gnunet-search` utility, as it could be a good test and
> example of usage for the bindings.

OK, sounds like a good plan!

Are you already using a public repo that we could look at?  If not, we
should set up a Git repository at gnunet.org or Savannah, whichever is
more convenient.

> Options handling: the standard way of writing software that uses
> GnuNet’s API is to let GnuNet handle the command line options: the
> API’s entry point, must be fed directly with the C arguments vector
> `argv`; it assures that all GnuNet programs have a uniform CLI. The
> first difficulty I encountred is: how to properly handle these
> options? After some work, I decided to manually craft a fake `argv` as
> a quick temporary fix.

OK.  Question for the GNUnet people: What’s the recommended way to
handle argc/argv if we want to provide a library?  Typically a Guile
module cannot be passed any arguments, and the initialization that
happens is just that its top-level forms are evaluated when it’s loaded.
Having to explicitly call an initialization function that takes an argv
would look unidiomatic.

> Variadic functions: these aren’t handled by Guile’s Dynamic FFI. As
> the only one I’ve encountred has been replaced with a non-variadic
> version in a separated C library.

I think I mentioned it before: In practice, we can manage to call
variadic functions from the FFI.  So you shouldn’t have to write any C
code.  Perhaps we could discuss the details on IRC?

> Data structures: main work has been the mapping of the huge
> ProgressInfo structure. GnuNet works with an event loop and you’re
> supposed, as a GnuNet API user, to provide a callback that will be
> used each time something happens in GnuNet’s File-Sharing
> subsystem. This callback is given a big structure, ProgressInfo, that
> contains every bit of information that could be needed. A good mapping
> of this structure is fundamental. For now, I’ve settled on a set of
> classes with a very simple hierarchy (one class for each type of
> event).

OK.  I must say I’m not fond of GOOPS, so I’d be curious to see the
code.  That shouldn’t block you, though.

Thank you for the update!

Ludo’.