Disir is confiuration entry management system. It implements a C library with plugin end-points to interact with pheripiral entries. A Command Line Interfacec (CLI) allows the user to interact and manage the conforming configurations available on his system.
This project was developed as a means to solve a specific problem that
should have a generic solution. Therefore, this implementation evolved with
a few mixed abstraction layers and some design choices that would not have been
made today. In an effort to document and thoroughly separate the abstractions that emerged,
a few Disir Specifications is an attempt to formalize the functionality and formats used.
These can be found in a dedicated repository.
Developers like to change their code; which often implies changing the configuration their code exposes to the end-user. Over time, when the user decides to update their system to the latest and greatest, they will be forced to handle the new configuration options and how it impacts his previously working setup.
Depending on your point of view, this has many caveats.
a) The developers should never make incompatible changes to their configuration file. How dare they! Assume that they didn’t make any incompatible changes, but rather added a ton of additional features that are all configured or intertwined with existing functionality, and to not break the previously working setup, this set of configuration keys and values must be present. If the user already has his old working copy of the configuration entry, he must now (manually) take care of updating his old configuration with the new values.
b) The end-user is such a pessemist! Here I come with my brilliant updates and he complains about the maintance of getting the system up-and-running after an upgrade! Seperating your code from the configuration the end-user has to interact with can be quite the pain. If one naievely maps exposed library configurations directly to the end-user, they might be exposed to way too much information that was unneccesary. This also makes changing the library very tiresome and grueling work, since the end-user is tied in with its (semi) internal workings. If only there was some middleman that can provide a clean, generic configuration entry interface to the end-user, whilst still give me the ability to iterate and improve my library. It would be even cooler if the updates I allow on my exposed configuration entry could go through an upgrade procedure at the end-user, so my semantically correct changes can propogate to their configuration, if applicable!
-
Generic C library to interface for full interaction with configuration entries and molds.
-
Plugin based interface to implement different sources of configuration entries. Default plugin implements reading configuration entries from JSON configuration files on disk, and reading the mold description for entries from JSON configuration files on disk.
-
Command Line Interface to interact with configuration entries.
-
Generate out-of-the-box configuration entries based on the associated mold.
-
Seemless semantic upgrade of previously generated configuration entries.
-
May require human intervention if both parties has modified a key-value pair.
-
-
Export and Import a archive of configuration entries.