- Kompliziert bauen kann jeder, die Einfachheit bestimmt unser Tun.
- -- Sergej Pawlowitsch Koroljow, Vater der sowjetischen Raumfahrt
Einer der Hypes, der schon seit einiger Zeit in der Softwareindustrie umgeht ist XML. Das Ganze steht für eXtensible Markup Language, was ich mal mit erweiterbare Beschreibungssprache übersetzen möchte.
Die Idee ist, nicht nur die Daten selbst, sondern auch eine Beschreibung wie diese Daten einzuordnen sind in der Datei mit abzulegen, und dies auf eine möglichst universelle und auch für einen Menschen eine nachvollziehbare Weise. Für größere Datenmengen, die auch noch zwischen verschiedenen Programmen ausgetauscht werden, ist dieses Vorgehen ein echter Segen, zumal man auch in den vielen Fällen für das Schreiben und Einlesen auf vorgefertigte Funktionen zurückgreifen kann. Eigentlich eine klasse Sache.
Nur leider wird es zuviel des Guten. Auf einmal wird XML als ein neues Allheilmittel angesehen, und möglichst jede paar Daten werden nun auf einmal als XML gesichert. Früher, als nur echte Männer sich an einen Computer getraut haben, und Architekten nur für Bauwerke und nicht für Software zuständig waren, da wurden einfache Daten auch einfach verwaltet.
Als Beispiel sei hier mal die Datei /etc/inittab genannt. Init ist traditionell das allererste Programm welcher ein Unix-Kernel startet. Dieses sorgt dann für den eigentlichen Systemstart und dafür dass die einzelnen Konsolen ihr Programm zum Anmelden laufen haben. Mann kann es auch dazu missbrauchen, dass ein wichtiges Systemprogramm neu gestartet wird, falls es abgestürzt ist.
Der Aufbau dieser Datei sieht wie folgt aus:
- alles nach einem Doppelkreuz ("#") ist ein Kommentar und wird nicht beachtet
- die Daten innerhalb einer Zeile gehören zusammen, die einzelnen Felder werden durch Doppelpunkte (":") getrennt
- die Bedeutung und Anordnung der Felder ist im Programm fest verdrahtet und wird anderweitig dokumentiert, zum Beispiel durch einen Kommentar in der Konfigurationsdatei und / oder einer Hilfe-Datei beziehungsweise Manpage.
Hier mal ein fiktives Beispiel:
# id:runlevels:action:process
1:23:respawn:/sbin/getty 38400 tty1
Und wie könnte das Gleiche in XML aussehen? Hier ist eine mögliche Variante:
<init>
<entry>
<id>1</id>
<runlevel>2</runlevel>
<runlevel>3</runlevel>
<action>respawn</action>
<process>/sbin/getty 38400 tty1</process>
</entry>
</init>
Und was hätten wir in diesem Fall nun durch den Einsatz von XML gewonnen? Meiner Meinung nach gar nichts. Wir würden uns durch den Einsatz einer Bibliothek für die Bearbeitung von XML nur eine weitere mögliche Quelle für Probleme einhandeln. Außerdem wird der Code und die Konfigurationsdatei nur größer.
Warum also nun dieser ganze Hype? Nun gut, man könnte argumentieren, dass man init ja nicht mit einer XML Konfigurationsdatei implementieren müsste. Aber etwas vergleichbares habe ich erste neulich in einem embedded(!) System gesehen. Dabei ging es nicht um init, sondern ein Programm, dass andere Prozesse überwacht und gegebenenfalls neu startet. Wer kommt nur auf solche Ideen? Über eine Antwort dieser Frage würde ich mich wirklich freuen.
Was ist nur aus dem
KISS-Prinzip geworden?
Kommentare
Sieht man sich das tradionelle Framework dafür an, stellen sich doch einige Fragen: Warum werden lokale ttys in der inittab verwaltet, die Netzwerk-Daemons über inetd und alle anderen Dienste über /etc/init.d und regelmäßige Jobs über die crontab (die auch keine Runlevel beachtet)? Warum kann man mit den bestehenden Konfigurationsdateien keine Abhängigkeiten zwischen Startup-Scripten ausdrücken (einige Distributionen machen das über Kommentare, die von Tools ausgewertet werden). Warum gibt es nur eine einstellige Anzahl von Runlevels, die auch noch uneinheitlich interpretiert werden? Alles nicht wirklich toll.
Aus diesem Gründen gibt es Alternativen, die meist das gesamte Problem angehen, wie z.B. upstart oder launchd. Eigentlich ist deren Konfigurationsformat ziemlich egal; zu den Hauptanforderungen zählt dann wohl, dass man strukturierte Daten abbilden kann und vor allen Dingen den verwendeten Zeichensatz angeben kann. Daher klingt XML für mich wie eine logische Wahl...