Wobei es auch da ja schon die beiden Quasi-Standards XML und JSON gibt, außerdem in gefühlt jeder Programmiersprache passende Libs, um mit diesen Dateien sinnvoll umzugehen... Heutzutage braucht man wirklich keine Configparser mehr selbst schreiben, wenn man nicht gerade eine (Pseudo-)Programmiersprache entwickelt...
Ich habe nichts gegen Elektra, es fällt mir "nur" etwas schwer zu verstehen, wo genau jetzt der Vorteil (aus Sicht eines Programmierers) daran liegt, dieses Framework zu benutzen.
Ein Programmierer hat da Vorteile, wo er den Konfigurationsstatus von anderen Anwendungen abfragen muss. Für die Configs seinr eigenen Programme hat es gegenüber XML und JSON keinen Vorteil, weil alle drei recht einfach per fertigem Parser oder API abgefragt werden können.
Aus Nutzersicht bietet Elektra eine einheitliche Konfigurationsschnittstelle, d.h. alles lässt sich darüber konfigurieren was Elektra nutzt und das ist schon ein sehr großer Vorteil.
Wobei es auch da ja schon die beiden Quasi-Standards XML und JSON gibt, außerdem in gefühlt jeder Programmiersprache passende Libs, um mit diesen Dateien sinnvoll umzugehen... Heutzutage braucht man wirklich keine Configparser mehr selbst schreiben, wenn man nicht gerade eine (Pseudo-)Programmiersprache entwickelt...
Es gibt noch viel mehr "Quasi-Standards" (YAML, TOML, ...). Elektra bietet den Vorteil, dass dem Benutzer die Wahlfreiheit nicht genommen wird, bzw. dass Distributionen "im Nachhinein" vereinheitlichen können.
Ich habe nichts gegen Elektra, es fällt mir "nur" etwas schwer zu verstehen, wo genau jetzt der Vorteil (aus Sicht eines Programmierers) daran liegt, dieses Framework zu benutzen.
Programmierer nehmen natürlich meistens das was in einem bereits verwendeten Framework mitgeliefert wird. Deswegen sind die Bemühungen von Elektra auch gleich bei diesen Frameworks anzusetzen (KDE, GNOME, ...).
Verwendet man noch kein Framework, bietet Elektra auch dem Programmierer Vorteile:
Code-Generierung: der Entwickler hat Code-Autocompletion und kann sich bei Config-Keys nicht vertippen
Validierungen mit guten Fehlermeldungen: der Entwickler muss nicht mit ifs alle Randfälle der Konfiguration beschreiben, sondern sagt deklarativ was erlaubt ist
Community: der Entwickler kann für viele Features auf fertige Plugins zurückgreifen (z.B. Notification: die Applikation bekommt sofort Updates wenn sich etwas geändert hat)
Portabilität: der Entwickler muss sich nicht für verschiedene Betriebsysteme überlegen von wo die Konfigurationsdateien gelesen werden sollen
Wobei es auch da ja schon die beiden Quasi-Standards XML und JSON gibt, außerdem in gefühlt jeder Programmiersprache passende Libs, um mit diesen Dateien sinnvoll umzugehen... Heutzutage braucht man wirklich keine Configparser mehr selbst schreiben, wenn man nicht gerade eine (Pseudo-)Programmiersprache entwickelt...
Ich habe nichts gegen Elektra, es fällt mir "nur" etwas schwer zu verstehen, wo genau jetzt der Vorteil (aus Sicht eines Programmierers) daran liegt, dieses Framework zu benutzen.
Ein Programmierer hat da Vorteile, wo er den Konfigurationsstatus von anderen Anwendungen abfragen muss.
Für die Configs seinr eigenen Programme hat es gegenüber XML und JSON keinen Vorteil, weil alle drei recht einfach per fertigem Parser oder API abgefragt werden können.
Aus Nutzersicht bietet Elektra eine einheitliche Konfigurationsschnittstelle, d.h. alles lässt sich darüber konfigurieren was Elektra nutzt und das ist schon ein sehr großer Vorteil.
Es gibt noch viel mehr "Quasi-Standards" (YAML, TOML, ...). Elektra bietet den Vorteil, dass dem Benutzer die Wahlfreiheit nicht genommen wird, bzw. dass Distributionen "im Nachhinein" vereinheitlichen können.
Programmierer nehmen natürlich meistens das was in einem bereits verwendeten Framework mitgeliefert wird. Deswegen sind die Bemühungen von Elektra auch gleich bei diesen Frameworks anzusetzen (KDE, GNOME, ...).
Verwendet man noch kein Framework, bietet Elektra auch dem Programmierer Vorteile: