Re: Can't specify different names for config file in project data

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--===============0058887535554761091==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="Uub8K5IcilvfogcWQYADj1M93K1DkXwqg"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--Uub8K5IcilvfogcWQYADj1M93K1DkXwqg
Content-Type: multipart/mixed; boundary="pleEo1fWScpq99EkhumJ4lYxgjghTxTal";
 protected-headers="v1"
From: Christian Grothoff <[email protected]>
To: [email protected]
Message-ID: <[email protected]>
Subject: Re: [bug-GNUnet] Can't specify different names for config file in
 project data
References: <[email protected]>
 <[email protected]>
 <[email protected]>
In-Reply-To: <[email protected]>

--pleEo1fWScpq99EkhumJ4lYxgjghTxTal
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

On 9/11/19 6:00 PM, Alessio Vanni wrote:
> Christian Grothoff <[email protected]> writes:
>=20
>> 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 no=
t
>> 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?
>=20
> 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.
>=20
> 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.


--pleEo1fWScpq99EkhumJ4lYxgjghTxTal--

--Uub8K5IcilvfogcWQYADj1M93K1DkXwqg
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE2EI7yzJseQcDOSnHk55r4eKfw8wFAl152ZoACgkQk55r4eKf
w8z2mBAAoGt0OmdFefcOiTO5PsDaV80ATglP9uS3edCsHCFmh7j12bpNLlRTLu/3
R2TYzeulLKgNjwTKwzeOrN4EjXoZOpjp9aZ5uPISXfoq/HXdJ+2sqIVa6cR/fism
Sbl6fsu2hHyDHR5vj512OrPOK+U9cOwXm8ZtG/0vJ8CD2xEwjw4Ram8WqUlf8pT2
iZhFJMpKTuI9pzL/Xr7ozZY8znuzH6Mj427qBfkFgWjEh769z61ITfwuvPVZRQke
Vhgl6+AksBPJ5bP9vo56AiBB6eCTZSGkPUQcHbAjc7igK0+UGbmSWOzm2sdfolbP
gf9v+mzXon5LzDm0vF4T4A7uWH+TNp8o+Gt53jEIPs031dUFeq+Gloy/3UYTh44l
aC4vGWN0RZmR5iDIhVtkBkqkTruFQJNg499DHjA/qrE51pjI+wLN4MTUIEsME3X8
WfDCLk82web4faVzlo+QWgcfOGxolmlJB1asqjhIi/0DIQN0vq2Qnj605IneDB4l
Ei8E5SBHDHJzfFEXRY6sCAMJEX73YaU+WdrIrY0hba6SYeLY0XyhQf4HxXW0MyIz
Dqadjmi6/8fZQgMz7i7onjEJQyxxzqmkzgVwah3DEExtMXK+2vFTOeFu9X6LcVSh
oYk9SU43UzwEkJSlnZ4rhjDoNt/1WQT5/R5rVPRynsMeMcKxj6g=
=M8S+
-----END PGP SIGNATURE-----

--Uub8K5IcilvfogcWQYADj1M93K1DkXwqg--


--===============0058887535554761091==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KQnVnLUdOVW5l
dCBtYWlsaW5nIGxpc3QKQnVnLUdOVW5ldEBnbnUub3JnCmh0dHBzOi8vbGlzdHMuZ251Lm9yZy9t
YWlsbWFuL2xpc3RpbmZvL2J1Zy1nbnVuZXQK

--===============0058887535554761091==--