Elektra 0.7.0

17/10/2008 - 20:06 von Markus Raab | Report spam
In mehreren Diskussionen hier ging es um verschiedene Konfigurations-
libraries[0]. Ich möchte hier keine Weitere vorstellen sondern in diesem
Projekt geht es um eine API und Datenstrukturen um alle anderen Libraries
und natürlich auch eigenen Parser und Generatorcode mittels Backends
einbinden zu können.

Der erste Schritt war die Festlegung der API, welches jetzt in der Version
0.7.0 [1] auch erledigt wurde. Es gibt jetzt keine direkten Abhàngigkeiten
zu einer bestimmten Art und Weise Konfiguration zu speichern. Damit sind
unglaublich viele verschiedene Ansàtze möglich[2].

Die KDB Datenstruktur (ein Trie) ermöglicht oben genannte Backends in
sogenannten Mountpoints in einer hierarchische Struktur einzubinden [3].
Dadurch ist gewàhrleistet dass die verschiedenen Backends gleichzeitig
verwendet werden können. Ein Administrator kann entscheiden für welche
Pfade (Applikationen) welches Backend zum Einsatz kommen soll. [4]

Der wichtigste Nebeneffekt einer solchen Abstraktion (das Programme
programmatisch auf Konfiguration ohne systemabhàngige Pfade zugreifen) ist
dass unterschiedliche Programme sich Konfiguration teilen können und damit
eine bessere Integration möglich wird.

C-Programme können jetzt sofort diese API verwenden und holen sich damit nur
eine zusàtzliche Abhàngigkeit (Elektra selber benötigt nur libc). Hier eine
kurze Anleitung wie die API aussieht und verwendet wird [5].

Das Backend Interface wird in einer kommenden Version noch geàndert,
Backends sollten derzeit nur geschrieben werden wenn möglicher
Anpassungsaufwand und Pionierdasein nicht gescheut wird. Die API und ABI
für Programme hingegen bleibt für 0.7.x mindestens ein Jahr unterstützt und
komplett kompatibel.

Obwohl Elektra 0.7.0 erst heute erschienen ist, wird es bereits durch
Oyranos[6] verwendet. Beispiele sind direkt in der Distribution, ein
riesiges Testingframework ist unter tests, kleine Qt3-basierte Programme
gibt es hier [7].

Allgemeine Informationen siehe: http://www.libelektra.org


mfg Markus


[0] msgid: <jdg0pnbctr.fsf@joerg.desch_at_gmx.net>
[1] https://svn.libelektra.org/svn/elektra/tags/0.7.0/
[2] http://www.libelektra.org/Backends
[3] http://www.markus-raab.org/ftp/elektra.pdf
[4] http://www.libelektra.org/GetStartedMounting
[5] http://www.libelektra.org/Tutorial
[6] http://www.oyranos.org/
[7] http://www.markus-raab.org/ftp/oel-elektra.tar.gz
http://www.markus-raab.org/ftp/wald...tra.tar.gz
 

Lesen sie die antworten

#1 Rainer Weikusat
19/10/2008 - 17:02 | Warnen spam
Markus Raab writes:
In mehreren Diskussionen hier ging es um verschiedene Konfigurations-
libraries[0]. Ich möchte hier keine Weitere vorstellen sondern in diesem
Projekt geht es um eine API und Datenstrukturen um alle anderen Libraries
und natürlich auch eigenen Parser und Generatorcode mittels Backends
einbinden zu können.



Ist Dir schon mal der Gedanke gekommen, dass zwischen einer
hierarchischen Datenbank, die anwendungsspezifische Datensaetze
enthaelt, und einem Verzeichnishierarchie, in der sich
anwendungsspezifische Dateien befinden, eine strukturelle Aequivalenz
besteht? Das Dateisystem ist ein einzelner, systemweiter
Namensraum. Das Problem, wenn man es ein solches nennen moechte, ist
die Unheitlichkeit der Konfiguration unterschiedlicher
Programme. Jetzt hat aber ein HTTP-Server wenig mit einem FTP-Server
und praktisch gar nichts mit einem X-Server gemein, dh ein guter Teil
dieser Uneinheitlichkeit ist funktional und nicht akzidentziell
verursacht. Ferner ist es wirklich unkompliziert, Textdateien mit
Hilfe von Standardwerkzeugen durch Skripte aendern zu lassen
('ed'). Ich habe hier ein komplettes Betriebsystem, das mit Sicherheit
'integrierter' ist, als eine Mehrzweck-Desktopinstalltion des je sein
wird, und das kommt wunderbar mit einer /etc-Hierarchie und
Textdateien aus. Wenn man lediglich Name-Wert-Paare speichern moechte
(eine Ordnungshierarchie stellt das Dateisystem zur Verfuegung), kann
man sich sogar eine 'Parser' schenken: Die shell hat naemlich schon
einen und sie kann Programme mit Kommandozeilenoptionen, in die
Shellvariablen hineininterpoliert wurden, ausfuehren. Natuerlich kann
man das alles auch anders machen, zB so, wie MS-Windows das tut. Dann
waere es eben anders (man kann aber zB auch einfach Windows benutzen,
wenn 'anders als Microsoft das implementiert hat' einen persoenlich
sehr stoert).

Mir erscheint auch eine Aussage wie 'Different distributions tend to
place different software configuration in different places with
different formats. A regular SuSE system administrator, for example,
will be lost when asked to work in a Debian or Slackware system.'
etwas exterm: Ich benutze privat Debian (sowie auf allen nicht-privaten
Computern, auf denen ich es einschmuggeln kann :-)). Der
Checkpoint-Kram, mit dem mein Arbeitgeber auch sein Geld verdient,
sollte eigentlich auf RHEL-laufen, befindet sich aus den ueblichen,
pragamatische Gruenden aber bei CentOS auch ganz wohl. Die meisten
Computer in den USA sind alte und teilweise uralte
SuSE-Installationen, obwohl die dankenswerterweise langsam
verschwinden (zB hat SuSE 8.x das mittlerweile getan). Dazu kommen
dann noch ein paar Ubuntus. Ich komme mir damit durchaus nicht
verloren vor und Kollegen, die auch mit diesen Maschinen zu tun haben,
sich wohl auch nicht. Unter anderem wird das dadurch ermoeglicht,
nicht vier verschiedene 'einfach benutzbare' frontends zur
Konfiguration derselben Dinge zu benutzen.

Ähnliche fragen