Re: Removal of GNUNET_CONFIGURATION_default() in 0.23

[Christian Grothoff]

Dear Alessio,

The idea is that programs like your should do two things:

1) implement their own 'project data' and point it to their own 
resources, and use that for GNUNET_PROGRAM_run(). The configuration you 
are given is then purely the configuration for your project.

2) when you do need to access GNUnet services, you MUST create a second 
configuration object, and this time use GNUNET_CONFIGURATION_create() 
and there pass the *GNUnet* project data. Here, the GNUnet configuration 
will be used (when do then 'load' it).

Then, pass the GNUnet configuration object to the GNUnet APIs, and use 
your configuration object for your own code.

I hope this clarifies the usage!

Happy hacking!

Christian

On 12/10/24 17:27, Alessio Vanni wrote:
> Hello,
>
> GNUnet 0.23 changed the way GNUNET_OS_ProjectData is used, moving it 
> from being global state to a function parameter in commit 
> 9ab62c62c3d508033d31ea5289013255ec7a0c87.
>
> The same commit also removes the GNUNET_CONFIGURATION_default function 
> to return a new configuration object with GNUnet's "default" values.
>
> This removal breaks third-party applications with a 
> GNUNET_OS_ProjectData that is different from GNUnet's own, because the 
> configuration object given as argument to the "main" function called by 
> e.g. GNUNET_PROGRAM_run does not contain the values GNUnet expects.
>
> I have attached a minimal test program to explain the issue. Compile it 
> with:
> gcc -o mybinary $(pkg-config --cflags gnunetutil) test.c $(pkg-config -- 
> libs gnunetutil)
>
> then start GNUnet and execute the mybinary program. You will see that 
> the program is not able to detect whether the GNS service is available 
> or not despite being running.
>
> The only way to make it work is to use GNUnet's configuration, but there 
> is no way to obtain it without replicating GNUnet's logic (reading env 
> variables, expanding paths, using defaults, etc.) which is something 
> third-party applications should never do.
>
> GNUNET_CONFIGURATION_create() only sets some path values, it does not 
> load the actual configuration and that makes it unsuitable to connect to 
> services due to missing important values found in each service's section 
> of the configuration.
>
> Applications which do not need to set a different project data value are 
> not affected, since they can use GNUnet's own one.
>
> Thank you,
> A. V.