[DOC] How to "mount" specific INI file in C ?

[Kochise]

Hi, just something that is bugging me for a little while.

While I can specific a storage plugin when mounting a INI file using the kdb command line tool, I cannot find anything similar with the C API. How to do that ?

Obviously many kdb example are simply not reproducible in C.

Regards.

[markus2330]

Hi,

at the moment there is no C API to do something similar as the kdb command does but we are working on that in the new backend branch.

At the moment the simplest thing you can do is to export a previously mounted configuration with the c plugin, e.g.:

kdb export "system:/elektra/mountpoints/system:\\/info\\/elektra\\/metadata\\/#0" c > mountpoint.c

And then simply use this KeySet in your C code, e.g.:

	Key * error_key = keyNew ("system:/elektra/mountpoints/system:\\/info\\/elektra\\/metadata\\/#0", KEY_END);
	KDB * kdb_handle = kdbOpen (0, error_key);

	KeySet * ks = ksNew (0, KS_END);
 	kdbGet (kdb_handle, ks, error_key);
	ksDel (ks)

	ks =
#include<mountpoint.c>
	kdbSet (kdb_handle, ks, error_key);
	ksDel (ks);

	kdbClose (kdb_handle, error_key);
	keyDel (error_key);

I hope this helps, otherwise do not hesitate to ask again! :heart: best regards, Markus

[markus2330]

Btw. please do not expect to work the same mountpoint.c across Elektra versions before 1.0. In the new backend branch we change how mountpoints look like.

[Kochise]

Thank for clarifying this though, because I was expecting this to be more trivial if I was going to "elektrify" an existing application.

It was already using an INI file, so I expected to be able to "mount" it like I used to using the INI wrapper library previously in charge, then access it "transparently" as before, with the benefit of Elektra plugins (storage, checker, ...).

Please do no break things too much, like the "cursor" thingies you're deprecating already.

I still have hard time figuring the whole "virtual path" that looks a bit "convoluted" for a "simple" configuration management system.

There is little explanation as to how use "metadata" with an exhaustive listing of them and their purpose.

Just like "specification" files, that are stored in INI "containers" but can only be used with the kdb command line tool.

Still working on the "cheat sheet" but getting things right is really harder than I initially thought though.

Regards.

[markus2330]

The currently recommended way is to call "kdb mount" during the installation of the program. For the high-level API such a script automatically gets generated. See also https://github.com/jonls/redshift/pull/837

Please do no break things too much,

We can only guarantee this after 1.0 not before :cry:

What exactly would you like to stay as is?

like the "cursor" thingies you're deprecating already.

Yes, we remove it, as the external iteration is vastly superior (iteration in every direction with every step width with an arbitrary number of iterators at the same time etc.).

I still have hard time figuring the whole "virtual path" that looks a bit "convoluted" for a "simple" configuration management system.

What exactly do you mean?

There is little explanation as to how use "metadata" with an exhaustive listing of them and their purpose.

Did you already see doc/METADATA.ini?

but can only be used with the kdb command line tool.

In Elektra, all parts can always read/written with any tool. Metadata is also part of the API.

Still working on the "cheat sheet" but getting things right is really harder than I initially thought though.

Very much looking forward to it! Please continue asking questions :wink:

[Kochise]

What exactly would you like to stay as is?

Things that makes the library usable without too much hassle to fight against. You know, the KISS one.

Btw, wouldn't be better to write array using "regular" array syntax ?

E.g. /sw/org/myapp/#0/current/message[0] instead of /sw/org/myapp/#0/current/message/#0

like the "cursor" thingies you're deprecating already.

Yes, we remove it, as the external iteration is vastly superior (iteration in every direction with every step width with an arbitrary number of iterators at the same time etc.).

Ok, your way, I can live with that.

I still have hard time figuring the whole "virtual path" that looks a bit "convoluted" for a "simple" configuration management system.

What exactly do you mean?

The main problem is the "mixture" of real path (so to speak) present in the configuration files (ecf, ini, ...) and the virtual "/sw/.../#0/profile" thing that isn't really clear what you access, where it is located, the purpose of, etc.

What is part of internal configuration, what is part of metadata, what is part of... to get a coarse/fine picture of things.

There is little explanation as to how use "metadata" with an exhaustive listing of them and their purpose.

Did you already see doc/METADATA.ini?

Yup I have.

Still working on the "cheat sheet" but getting things right is really harder than I initially thought though.

Very much looking forward to it! Please continue asking questions 😉

I'd like to have it clarified as much as possible for the first draft otherwise it might take to wrong path and further changes may scramble it some more. But indeed it shall be release for review at one point.

[Kochise]

Just to be sure, will Elektra 1.x C/Lua/... API features opening/mounting other file formats like kdb does ?

[kodebach]

Yes, for 1.x we want to replace all the C++ code that is currently used for mounting (in src/lib/tools) with C code. This will also allow us to provide proper C APIs for mounting.

In the meantime you could use the C++ API, or look at what kdb mount writes to system:/elektra/mountpoints for your particular case and replicate that manually with the existing C API. However, neither solution is recommended for a production deployment, since there will be significant changes for 1.0

[markus2330]

Btw, wouldn't be better to write array using "regular" array syntax ?

We wanted to have a shell-friendly syntax and [] needs to be escaped. Furthermore, the /#/ syntax (# in between does not have special meaning) better fits the concepts how key names and their hierarchy work.

The main problem is the "mixture" of real path (so to speak) present in the configuration files (ecf, ini, ...) and the virtual "/sw/.../#0/profile" thing that isn't really clear what you access, where it is located, the purpose of, etc.

kdb file and verbose error messages should always point you where the underlying files are located. Ideally, you never need "real" paths but unfortunately we are nowhere near that this could be realized soon, thus the mixture.

What is part of internal configuration, what is part of metadata, what is part of... to get a coarse/fine picture of things.

It is so simple that we missed to say it explicitly: Only /elektra is internal. Metadata is a very simple concept but fundamentally different to all other current databases, thus it is very confusing at first: there are different meta-levels encoded with one syntax in a single key database, maybe https://archive.fosdem.org/2018/schedule/event/elektra/ makes you help understand the main purpose of metadata (i.e. configuration specifications)?

Just to be sure, will Elektra 1.x C/Lua/... API features opening/mounting other file formats like kdb does ?

@kodebach already answered for C: it is an important goal for us and thanks to two new people who joined Elektra (@atmaxinger and @flo91) we hopefully have the man power to realize it. If we will be able to write libtools bindings for a specific language (you mentioned Lua) cannot be answered. Currently, we don't have a Lua maintainer, we simply keep the Lua binding compiling and tests running, without new features. Contributions welcomed.

[markus2330]

@flo91 as discussed, it is an important goal to have a C library for mounting. It would be a good start to define an API for mounting, ideally in a PR.

[github-actions[bot]]

I mark this stale as it did not have any activity for one year. I'll close it in two weeks if no further activity occurs. If you want it to be alive again, ping by writing a message here or create a new issue with the remainder of this issue. Thank you for your contributions :sparkling_heart:

[github-actions[bot]]

I closed this now because it has been inactive for more than one year. If I closed it by mistake, please do not hesitate to reopen it or create a new issue with the remainder of this issue. Thank you for your contributions :sparkling_heart: