XML ist tatsächlich nicht besonders gut für Konfigurationsdateien geeignet, z.b. da XML Dateien üblicherweise nach erneutem Schreiben anders ausiehen (so genannter roundtrip, z.b. wegen CDATA).
Deshalb ist XML in Elektra nur eine von dutzenden möglichen Konfigurationsformaten.
XML dürfte am Alter des Projekts liegen. Wobei XML immer noch am verbreitetsten ist. Wenn es darum geht ein Format zu haben, welches möglichst viele Libs, Programmiersprachen und Co. unterstützt, steht XML zumindest auf der Liste.
Was wäre den eine Alternative? JSON fällt mir da ein. Irgendwie sollte es schon ein Format mit breiter Unterstützung sein. Auch wenn Ekiga das ansich intern lösen sollte.
Dass die das Registry genannt haben, maximiert aber sowieso die Nicht-Akzeptanz bei den Anwendern. Was den aktuellen Erfolgt des Projekts erklärt.
Danke für die Erläuterung. JSON hab ich zu meiner Schande vorher noch nie gehört. Ich bin aber auch nicht aus der Branche. XML kann also als obsolete angesehen werden?
Alles hat seine Vor- und Nacheile. Grob würde ich mal sagen: - Für kleine Sachen langen meist Properties (insbesondere mit Keys wie "einBereich.meinKey=Mein Value"). - Wenns strukturierter sein muss, aber noch übersichtlich ist, dann nimm Json. - Wenns komplex ist, Schema und Tooling verlangt oder zumindest hilfreich sind, oder spezielle Sachen wie Krypto oder embedded Teile verlangt werden, dann nimm XML. Wenn wir von Konfig-Sachen reden, sind also zu 80 % Properties ausreichend und der Rest mit Json machbar. Wer mehr für Konfig braucht, hat IMHO ein Fehldesign in der App ... Ganz miese Beispiele findest du bei Mailern und beim Apache Http - sagen wir mal: Wenns Bücher zur Konfiguration eines Programmes bedarf, ist starker Verbesserungsbedarf kaum auszuschliessen ;-) Cheeers!
P.S.: Pro App eine Konfig an einer best. Stelle im JSON-Format mit Javascript als schneller Interpreter, das wärs!! (1000 mal besser als eine registry- XML- oder gar dienstebasierende Sache.)
Ein Dienst ist halt notwendig, wenn nicht jedes Programm fswatches installieren soll,um über Änderungen informiert zu werden. Zudem erlaubt er es konkurrierende Wertänderungen zu verwalten, also race conditions zu vermeiden.
XML ist nur eines der unterstützen Speicherformate, speziell für Prozesse im "early boot" benutzt Elektra viel einfachere Möglichkeiten, weil zu diesem Zeitpunkt potentiell noch keine XML Parser geladen werden können.
Das einfachste Speichermodell bildet Einträge auf einzelne Dateien ab.
Dass die das Registry genannt haben, maximiert aber sowieso die Nicht-Akzeptanz bei den Anwendern. Was den aktuellen Erfolgt des Projekts erklärt.
"Linux Registry" war der Name, den der ursprüngliche Entwickler Anfang der 2000er benutzt hatte, um auszudrücken, dass das Ziel eine einheitliche Konfiguration für alle Belange des Systems ist.
Das Projekt heißt schon Ewigkeiten Elektra, aber die üblichen Trolle greifen das natürlich immer auf, weil es ein guter Einstieg für sie ist. Und wie man am Beispiel hier sieht, auch Erfolg damit haben: selbst dein ansich hiervorragender Kommentar greift es noch mal auf. Der Troll vom Anfang freut sich sicher darüber.
gsettings, der Nachfolger von gconf, braucht eigentlich auch nicht zwingend einen daemon, aber hat ihm aus folgenden gründen: - Benachrichtigung bei Wertänderungen: wenn bspw ein theme geändert wird, dann soll das jeder mitbekommen
- Verwendung eines Binärformates für schnellen Lesezugriff: standardgemäß wird in home binär gespeichert, aber es gibt bei dconf, dem Datenbackend, mehrere Möglichkeiten. Ist home auf NFS, so ist man beispielsweise angehalten dort im INI-Format zu speichern und den Daemon die Daten irgendwo unter /var binär speichern zu lassen. Im falle von Änderungen wird beides synchron gehalten.
Das Binärformat reisst es ganz bestimmt raus *lol* Dass die meisten Einstellungen sehr klein (< 4 kb) und Strings sind, ist an den Performance-Meistern wohl vorbeigegangen. Und dass man diese mit Faktor 10 einfach zippen kann, was niemand tut, weils nichts bringt - siehe Punkt 1 - wohl auch. Nö, da muss ein "hochoptimiertes" Binärformat ran - mit dem man sich selbst in den Fuß schiesst. Voll am Ziel vorbei würde ich sagen. *kopfschüttel*
Und du glaubst nicht, dass man sich da Gedanken gemacht hat, nachdem man Erfahrungen mit gconf hatte,welches ein reines Textformat hat?
Die Prämisse ist das Lesen zu optimieren und man hat bei jedem Login tausende Abfragen in den Configdaten, was schlägt der Herr Forenspezialist denn vor?
Eine Windows-Registry im XML-Format für Linux... kill it with fire!
Besser hätte man es fast nicht ausdrücken können.
Wieso zum Deibel nimmt man für sowas dann XML statt "richtige" Sachen...
Und warum ist XML nichts, bzw für diesen Anwendungsfall nicht?
XML ist tatsächlich nicht besonders gut für Konfigurationsdateien geeignet, z.b. da XML Dateien üblicherweise nach erneutem Schreiben anders ausiehen (so genannter roundtrip, z.b. wegen CDATA).
Deshalb ist XML in Elektra nur eine von dutzenden möglichen Konfigurationsformaten.
XML dürfte am Alter des Projekts liegen.
Wobei XML immer noch am verbreitetsten ist. Wenn es darum geht ein Format zu haben, welches möglichst viele Libs, Programmiersprachen und Co. unterstützt, steht XML zumindest auf der Liste.
Was wäre den eine Alternative? JSON fällt mir da ein. Irgendwie sollte es schon ein Format mit breiter Unterstützung sein. Auch wenn Ekiga das ansich intern lösen sollte.
Dass die das Registry genannt haben, maximiert aber sowieso die Nicht-Akzeptanz bei den Anwendern. Was den aktuellen Erfolgt des Projekts erklärt.
Danke für die Erläuterung. JSON hab ich zu meiner Schande vorher noch nie gehört. Ich bin aber auch nicht aus der Branche. XML kann also als obsolete angesehen werden?
Alles hat seine Vor- und Nacheile.
Grob würde ich mal sagen:
- Für kleine Sachen langen meist Properties (insbesondere mit Keys wie "einBereich.meinKey=Mein Value").
- Wenns strukturierter sein muss, aber noch übersichtlich ist, dann nimm Json.
- Wenns komplex ist, Schema und Tooling verlangt oder zumindest hilfreich sind, oder spezielle Sachen wie Krypto oder embedded Teile verlangt werden, dann nimm XML.
Wenn wir von Konfig-Sachen reden, sind also zu 80 % Properties ausreichend und der Rest mit Json machbar. Wer mehr für Konfig braucht, hat IMHO ein Fehldesign in der App ... Ganz miese Beispiele findest du bei Mailern und beim Apache Http - sagen wir mal: Wenns Bücher zur Konfiguration eines Programmes bedarf, ist starker Verbesserungsbedarf kaum auszuschliessen ;-)
Cheeers!
P.S.: Pro App eine Konfig an einer best. Stelle im JSON-Format mit Javascript als schneller Interpreter, das wärs!! (1000 mal besser als eine registry- XML- oder gar dienstebasierende Sache.)
Ein Dienst ist halt notwendig, wenn nicht jedes Programm fswatches installieren soll,um über Änderungen informiert zu werden. Zudem erlaubt er es konkurrierende Wertänderungen zu verwalten, also race conditions zu vermeiden.
Welche Distribution hat den fswatches schon als Paket? Oder meinst du eher inotify?
ich meinte dateisystemwatches i.A., das Paket kannte ich nicht
Das einfachste Speichermodell bildet Einträge auf einzelne Dateien ab.
"Linux Registry" war der Name, den der ursprüngliche Entwickler Anfang der 2000er benutzt hatte, um auszudrücken, dass das Ziel eine einheitliche Konfiguration für alle Belange des Systems ist.
Das Projekt heißt schon Ewigkeiten Elektra, aber die üblichen Trolle greifen das natürlich immer auf, weil es ein guter Einstieg für sie ist.
Und wie man am Beispiel hier sieht, auch Erfolg damit haben: selbst dein ansich hiervorragender Kommentar greift es noch mal auf. Der Troll vom Anfang freut sich sicher darüber.
gsettings, der Nachfolger von gconf, braucht eigentlich auch nicht zwingend einen daemon, aber hat ihm aus folgenden gründen:
- Benachrichtigung bei Wertänderungen: wenn bspw ein theme geändert wird, dann soll das jeder mitbekommen
- Verwendung eines Binärformates für schnellen Lesezugriff: standardgemäß wird in home binär gespeichert, aber es gibt bei dconf, dem Datenbackend, mehrere Möglichkeiten. Ist home auf NFS, so ist man beispielsweise angehalten dort im INI-Format zu speichern und den Daemon die Daten irgendwo unter /var binär speichern zu lassen. Im falle von Änderungen wird beides synchron gehalten.
Das Binärformat reisst es ganz bestimmt raus *lol*
Dass die meisten Einstellungen sehr klein (< 4 kb) und Strings sind, ist an den Performance-Meistern wohl vorbeigegangen.
Und dass man diese mit Faktor 10 einfach zippen kann, was niemand tut, weils nichts bringt - siehe Punkt 1 - wohl auch.
Nö, da muss ein "hochoptimiertes" Binärformat ran - mit dem man sich selbst in den Fuß schiesst. Voll am Ziel vorbei würde ich sagen. *kopfschüttel*
Und du glaubst nicht, dass man sich da Gedanken gemacht hat, nachdem man Erfahrungen mit gconf hatte,welches ein reines Textformat hat?
Die Prämisse ist das Lesen zu optimieren und man hat bei jedem Login tausende Abfragen in den Configdaten, was schlägt der Herr Forenspezialist denn vor?