Re: [bug-GNUnet] Can't specify different names for config file in project data

[Christian Grothoff]

On 9/11/19 6:00 PM, Alessio Vanni wrote:
> Christian Grothoff <address@hidden> writes:
> 
>> Ok, then I'm not sure how you expect this to work: if you do not give
>> the code access to the configuration data (i.e. by telling it to load it
>> from a different directory than where GNUnet was installed and also not
>> providing the right configuration information in that directory), then
>> obviously the logic will fail when it needs its configuration.
>>
>> Note that you can use GNUNET_CONFIGURATION_load* with the "right"
>> path(s) to manually load either the GNUnet configuration data or your
>> own applications' configuration data (if they are in different
>> locations). However, without such manual action on your part,
>> libgnunetutil will by design only load the configuration data from the
>> one location that is configured via the ProjectData mechanism.
>>
>> Does this help?
> 
> I'm not sure if I understood correctly what you mean, so let me list
> what I know about how configuration works.  It might be wrong and that's
> why I'm doing this.
> 
> When I define the ProjectData structure, I specify that I want my
> application to look for a certain configuration file.  Because I want
> this file to be specific to my application, I don't use the GNUnet's
> file, but something else (say, "test-program.conf" and
> "~/.test-program.d/config")

That's already not the suggested approach. If you want to interact with
GNUnet because you are working on top of GNUnet, you should not override
_either_ value. GNU Taler overrides these values, but GNU Taler does
_not_ want to interact with GNUnet services!

What you should do -- if you want to have your "own" configuration (and
use the libgnunetutil configuration parser) -- is to load your
configuration using GNUNET_CONFIGURATION_create/load APIs providing your
own application paths explicitly there. However, that configuration
object must then not be used to interact with GNUnet services. So you'd
basically have two configuration handles: one or your own application
(which you'd use internally), and one which you'd pass to GNUnet APIs.


Now, if you do not merely want to use your own configuration, but also
use the GNUnet *service* API, then you _may_ override ProjectData to use
your own configuration location. However, if you then want to interact
with GNUnet services, you _MUST_ make a backup of the "old" project data
(or somehow have some other means of determining the "correct" GNUnet
configuration location, i.e. using the GNUNET_OS_install_path() API) and
again create/load the GNUnet configuration when creating a configuration
handle to interact with GNUnet services.

> Ultimately what I'm expecting is that on initialization the application
> loads GNUnet's settings (mainly to find the services' port/sockets) and
> then its own settings.  Is that a wrong assumption to make?

It's not wrong, just if you decided to have two configuration locations,
then you must manage two configuration objects and pass the "right" one
at the right time.  Managing this is not something libgnunetutil can do
for you.

signature.asc
Description: OpenPGP digital signature