gnunet-developers
[Top][All Lists]
Advanced

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

[GNUnet-developers] GSoC: Binary package distribution through GnuNet (re


From: asgeir
Subject: [GNUnet-developers] GSoC: Binary package distribution through GnuNet (report 1)
Date: Wed, 3 Jun 2015 15:38:06 +0200 (CEST)

Hello,

it is high time I send you my first report, as the coding period
started last week. In the process of implementing package distribution
through GnuNet, I started writing Guile bindings.

During the community bonding period, besides the documentary work,
I’ve headed to the two first problems: options handling and variadic
functions.

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.

More detailed explanations:

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.

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.

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

If you have any suggestion or question, please feel free to contact
me!
--
Rémi



reply via email to

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