Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

write storage plugins with existing parsers #1231

Open
5 tasks
markus2330 opened this issue Dec 24, 2016 · 3 comments
Open
5 tasks

write storage plugins with existing parsers #1231

markus2330 opened this issue Dec 24, 2016 · 3 comments

Comments

@markus2330
Copy link
Contributor

markus2330 commented Dec 24, 2016

Hello newcomer,

Elektra's goal is to integrate current forms of configuration files. The best way to integrate them is to use ready-made parsers, then Elektra uses exactly the same code to access configuration files as the application. Some ideas for such libraries (random order):

You should prefer to pick the ones you are familar with, which are popular, are well maintained, and provide a easy-to-use API.

To get support for a new file format with a new parser, you have to create a new plugin (see https://github.com/ElektraInitiative/libelektra/blob/master/doc/tutorials/plugins.md and https://github.com/ElektraInitiative/libelektra/blob/master/doc/tutorials/storage-plugins.md). You only have to implement kdbGet and kdbSet:

  • in kdbGet you first you look into the string of the parentKey and open the configuration file of this name. Then you iterate over all keys you get from the library and transform them into a keyset.
  • in kdbSet you do the opposite: you iterate over the keyset and feed it to the library. Again you use the string of the parentKey to know where to write the content to.

A Plugin that already does exactly this are https://tree.libelektra.org/src/plugins/ni (you can ignore metakey and metavalue for a first step)

To complete the task, please:

  • implement as described above for one configuration parsing library
  • fully fill out README.md. For tricky parts (provides, placements) you can peek into the READMEs of other storage plugins.
  • handle all errors (also peek in other storage plugins what to do on I/O errors)
  • add unit tests demonstrating that a file read and written again stays the same (you guessed it, other storage plugins do the same)
  • remove not needed parts of template (open, close, error)

Please write something below before starting the task. You can always ask here for help.

markus2330 pushed a commit that referenced this issue Dec 27, 2016
@markus2330 markus2330 added cm2022s for university course and removed cm2022s for university course labels Feb 19, 2021
@flo91
Copy link
Collaborator

flo91 commented Oct 5, 2022

@markus2330 Should we offer this issue for the FLOSS course?

@kodebach
Copy link
Member

kodebach commented Oct 5, 2022

As an extension to the more common formats above I'd like to suggest: https://kdl.dev/

It's hierarchical, supports multiple values per node (= arrays) and nodes can have additional named properties (= metadata). I think the format can store the same data as a KeySet. There are also suitable parsers in Rust and C (among other languages).

@markus2330
Copy link
Contributor Author

@markus2330 Should we offer this issue for the FLOSS course?

I rather not advertise it. Writing a useful storage plugin (also preserving order, comments etc.) is not so easy. And storage plugins need maintenance afterwards, as it takes some time to find tricky issues. So I would prefer if someone improves e.g. TOML (#4466 #3478) than creating a new storage plugin.

https://kdl.dev/

👍 I added it in the list above.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants