Unterschiede (Vor- und Nachteile) vom XML gegenüber Ini-Dateien

[minhen]

rüdiger schrieb:

Wie gesagt, es gibt alternative Formate, die leichter zu parsen sind (und leichter in eine Vernünftige Datenstruktur konvertierbar sind) und nach meiner Meinung auch leichter lesbar sind

Mal angenommen du hättest recht, so ist die einzige brauchbare Alternative, die du genannt hast, YAML. Und auch das kann XML leider (noch?) nicht das Wasser reichen. Dabei geht's noch nicht mal darum, ob

YAML Working Draft schrieb:

This specification is a draft reflecting consensus reached by members of the yaml-core mailing list.

als Spezifikation und Standardisierungsorganisation besser oder schlechter ist als

Extensible Markup Language W3C Recommendation schrieb:

This document specifies a syntax created by subsetting an existing, widely used international text processing standard (Standard Generalized Markup Language, ISO 8879:1986(E) as amended and corrected) for use on the World Wide Web. It is a product of the XML Core Working Group as part of the XML Activity. (...) This document is a W3C Recommendation.

sondern darum, dass XML schlicht produktiver ist. Eine Infrastruktur, die sich mit der von XML verlgeichen lassen könnte, fehlt bei YAML einfach. Die Gründe dafür stecken ja auch schon in den Zitaten. Das ist ein Punkt, der nicht zu verachten ist. Das kann sich in Zukunft vielleicht auch für YAML verbessern, aber Stand jetzt fährt man mit XML schlicht "sicherer" und bequemer.

[Blue-Tiger]

minhen schrieb:

rüdiger schrieb:

Wie gesagt, es gibt alternative Formate, die leichter zu parsen sind (und leichter in eine Vernünftige Datenstruktur konvertierbar sind) und nach meiner Meinung auch leichter lesbar sind

Mal angenommen du hättest recht, so ist die einzige brauchbare Alternative, die du genannt hast, YAML. Und auch das kann XML leider (noch?) nicht das Wasser reichen. Dabei geht's noch nicht mal darum, ob

YAML Working Draft schrieb:

This specification is a draft reflecting consensus reached by members of the yaml-core mailing list.

als Spezifikation und Standardisierungsorganisation besser oder schlechter ist als

Extensible Markup Language W3C Recommendation schrieb:

This document specifies a syntax created by subsetting an existing, widely used international text processing standard (Standard Generalized Markup Language, ISO 8879:1986(E) as amended and corrected) for use on the World Wide Web. It is a product of the XML Core Working Group as part of the XML Activity. (...) This document is a W3C Recommendation.

sondern darum, dass XML schlicht produktiver ist. Eine Infrastruktur, die sich mit der von XML verlgeichen lassen könnte, fehlt bei YAML einfach. Die Gründe dafür stecken ja auch schon in den Zitaten. Das ist ein Punkt, der nicht zu verachten ist. Das kann sich in Zukunft vielleicht auch für YAML verbessern, aber Stand jetzt fährt man mit XML schlicht "sicherer" und bequemer.

Es geht hier immer noch um Konfigurationsdateien, nicht um die eierlegende Wollmilchsau um alle moeglichen strukturierten Texte abzuspeichern. Und da brauch ich keine grosse Infrastruktur

[SideWinder]

Das schöne an XML ist, dass du nur das benutzt was du benötigst. Wie gesagt: Leichter als mit TinyXML kann ichs mir kaum vorstellen

MfG SideWinder

[rüdiger]

@minhen
Warum ist YAML die einzige alternative? Warum fährt man "sicherer" mit XML? Welche Infrastruktur meinst du?

Ich fand die XML-Infrastruktur eher dürftig. Zwar gibt es für viele Dinge zusätzliche Spezifikationen, aber ich hatte in vielen Fällen das Problem dafür passende Implementierungen zu finden. Vor allem gibt es für alles verschiedene Spezifikationen, was auch die Interoperabilität einschränkt oder einige Dinge sind gar nicht finalisiert und ändern sich regelmäßig (dabei die ganzen anderen Buzzword-Technologien, wie SOAP, XML-Schemas (die eh nicht sinnvoll benutzbar sind, weil die Implementierungen dafür grotten lahm, komplex und gigantisch sind), XQuery etc.). Dann benötigen viele Technologien extra Parser (zB DTD, XPath, XQuery), was die ganzen XML-Implementierungen aufbläht. Daher findet man oft Parser, die entweder immer zu wenig können oder viel zu viel.

Und für das eigentliche Thema, Konfigurationsdateien braucht man eher ein sinnvolles Mapping von Datenstrukturen in der Programmiersprache zu Datenstrukturen im Textformat und da ist XML eben nicht optimal für (Attribute sind bei so etwas schädlich, was auch wieder so ein "historischer" Ballast aus dem Markup-Bereich ist).

[.filmor]

minhen schrieb:

Extensible Markup Language W3C Recommendation schrieb:

This document specifies a syntax created ... for use on the World Wide Web ...

!

XML ist meiner Meinung nach ne tolle Sache, aber (im Allgemeinen) nicht für Konfigurationsdateien, sondern eher für etwas, was in irgendeiner Weise mit Browsern in Berührung kommen könnte.

[jemand aus dem wald]

Bezüglich den XML Conformance Tests kann ich den Link nachreichen: http://www.oasis-open.org/committees/xml-conformance/

rüdiger schrieb:

Daher findet man oft Parser, die entweder immer zu wenig können oder viel zu viel.

Deiner Meinung nach ist es also die "Schuld" von XML, dass sich darum weitere Standards gebildet haben? Dem kann man doch absolut zustimmen. Ich würde sogar so weit gehen HTTP die Schuld an "Buzzword-Technologien" wie SOAP zu geben ...

rüdiger schrieb:

Und für das eigentliche Thema, Konfigurationsdateien braucht man eher ein sinnvolles Mapping von Datenstrukturen in der Programmiersprache zu Datenstrukturen im Textformat und da ist XML eben nicht optimal für

Wie ich eigentlich bereits erwähnt habe, ist das sehr wohl möglich, so "unoptimal" XML auch dafür sein mag.

http://jakarta.apache.org/commons/digester/ schrieb:

Many Jakarta projects read XML configuration files to provide initialization of various Java objects within the system. There are several ways of doing this, and the Digester component was designed to provide a common implementation that can be used in many different projects.

Basically, the Digester package lets you configure an XML -> Java object mapping module, which triggers certain actions called rules whenever a particular pattern of nested XML elements is recognized. [...]

.filmor schrieb:

XML ist meiner Meinung nach ne tolle Sache, aber (im Allgemeinen) nicht für Konfigurationsdateien, sondern eher für etwas, was in irgendeiner Weise mit Browsern in Berührung kommen könnte.

Ich würde dir ja gerne Beispiele für C++ Projekte nennen, die sich für eine XML Konfigurationsdatei entschieden haben, aber das ist nicht mein Metier. Stattdessen kann ich dir halt Hibernate Mapping Dateien, Spring Konfigurationsdateien, etc. empfehlen, die allesamt mit XML gut beraten sind.

[DEvent]

Ohman was für'n Diskussion. Dabei ist es doch ganz einfach:
Ini-Dateien sind nirgendwo standardisiert, jeder Programmierer denkt sich sein eigenes Format aus. Zumindest habe ich noch nie von einem ini-Standard gehört.

Wenn du ohne groß nachdenken Daten abspeichern willst, würde ich XML nehmen, weil es genug Leute gibt, die sich tagtäglich mit dem Standard beschäftigen und Parser bauen. Dabei hast du den Vorteil das sich das XML-Format abwärts- und aufwärstkompatibel bleibt. Das heißt du kannst einen x belieben Parser nehmen und kannst Daten in deine Config-Datei schreiben und lesen.

Dabei hast du noch den Vorteil das XML eine Baumstruktur ist, Attribute hat, namespaces usw.

Also kurzum: Ini-datei: Kein Standard, XML: Standard.

Konkretes Beispiel: Öffne einfach /etc/samba/smb.conf (oder eine andere Konfigurationsdatei deiner Wahl, die sozusagen das INI Format benutzt) mit Notepad.

Was soll da passieren? Bis auf die Tatsache das die Config-Datei ziemlich unübersichtlich ist.

Also ich find's unübersichtlich. Da steht so ein [global] bis wohin gilt das wohl? Ausserdem kann man die einzelnen Einstellungen mischen, also in Zeile 50 eine Zeile printer-Setting, in Zeile 10 dann socket options und in Zeile 100 irgendwas vom cd-rom.

XML wäre da weitsaus übersichtlicher.

[jemand aus dem wald]

DEvent schrieb:

Was soll da passieren? Bis auf die Tatsache das die Config-Datei ziemlich unübersichtlich ist.

Naja, und glaubst der Parser wird sie übersichtlicher "sehen"? Bevor du jetzt fragst, ob es dem Parser nicht schei*egal sein kann, wie übersichtlich eine Datei ist, denk einfach noch ein wenig weiter.

[Blue-Tiger]

DEvent schrieb:

Ohman was für'n Diskussion. Dabei ist es doch ganz einfach:
Ini-Dateien sind nirgendwo standardisiert, jeder Programmierer denkt sich sein eigenes Format aus. Zumindest habe ich noch nie von einem ini-Standard gehört.

Wenn du ohne groß nachdenken Daten abspeichern willst, würde ich XML nehmen, weil es genug Leute gibt, die sich tagtäglich mit dem Standard beschäftigen und Parser bauen. Dabei hast du den Vorteil das sich das XML-Format abwärts- und aufwärstkompatibel bleibt. Das heißt du kannst einen x belieben Parser nehmen und kannst Daten in deine Config-Datei schreiben und lesen.

Dabei hast du noch den Vorteil das XML eine Baumstruktur ist, Attribute hat, namespaces usw.

Also kurzum: Ini-datei: Kein Standard, XML: Standard.

Konkretes Beispiel: Öffne einfach /etc/samba/smb.conf (oder eine andere Konfigurationsdatei deiner Wahl, die sozusagen das INI Format benutzt) mit Notepad.

Was soll da passieren? Bis auf die Tatsache das die Config-Datei ziemlich unübersichtlich ist.

Also ich find's unübersichtlich. Da steht so ein [global] bis wohin gilt das wohl? Ausserdem kann man die einzelnen Einstellungen mischen, also in Zeile 50 eine Zeile printer-Setting, in Zeile 10 dann socket options und in Zeile 100 irgendwas vom cd-rom.

XML wäre da weitsaus übersichtlicher.

Hmmmm... Also wie ein INI-File auszusehen hat weiss wohl jeder, dazu brauchts ja dann wohl keinen Standard Im Gegensatz zu XML, was kompliziert (sprich: umfangreich) genug ist um einen Standard zu brauchen. Wenn ich's mir aussuchen koennt, wo ich als Benutzer lieber rumfrickel, dann definitiv in INI-Files. Your mileage may vary.

[THX 1138]

Oh my god (musst ich jetzt einfach mal sagen)

Wo ist euer Problem? Er will Konfigurationen speichern

Section "Screen"
    Identifier     "Default Screen"
    Device         "Geforce"
    Monitor        "iiyama ProLite E1900S"
    DefaultDepth    24
    SubSection     "Display"
        Depth       24
        Modes      "1280x1024" "1280x960" "1152x864" "1024x768" "800x600" "640x480"
    EndSubSection
EndSection

Selbsterklärend und "human-readable" *bingo*

# An HTML'ized description of all settings (based on comments in this file,
# with alphabetical table of settings and with table of settings by category)
# is available at http://www.hippo.ru/~hvv/lynxcfg_toc.html
#
### The conversion is done via the scripts/cfg2html.pl script.
### Several directives beginning with '.' are used for this purpose.

.h1 Auxiliary Facilities
# These settings control the auxiliary navigating facilities of lynx, e.g.,
# jumpfiles, bookmarks, default URLs.

.h2 INCLUDE
# Starting with Lynx 2.8.1, the lynx.cfg file has a crude "include"
# facility.  This means that you can take advantage of the global lynx.cfg
# while also supplying your own tweaks.
#
# You can use a command-line argument (-cfg /where/is/lynx.cfg) or an
# environment variable (LYNX_CFG=/where/is/lynx.cfg).
# For instance, put in your .profile or .login:
#
#   LYNX_CFG=~/lynx.cfg; export LYNX_CFG   # in .profile for sh/ksh/bash/etc.
#   setenv LYNX_CFG ~/lynx.cfg             # in .login for [t]csh
#
# Then in ~/lynx.cfg:
#
#   INCLUDE:/usr/local/lib/lynx.cfg
#           ^^^^^^^^^^^^^^^^^^^^^^^ or whatever is appropriate on your system
# and now your own tweaks.
#
# Starting with Lynx 2.8.2, the INCLUDE facility is yet more powerful.  You can
# suppress all but specific settings that will be read from included files.
# This allows sysadmins to provide users the ability to customize lynx with
# options that normally do not affect security, such as COLOR, VIEWER, KEYMAP.
#
# The syntax is
#
#   INCLUDE:filename for <space-separated-list-of-allowed-settings>
#
# sample:
.ex
#INCLUDE:~/lynx.cfg for COLOR VIEWER KEYMAP
# only one space character should surround the word 'for'.  On Unix systems ':'
# is also accepted as separator.  In that case, the example can be written as
.ex
#INCLUDE:~/lynx.cfg:COLOR VIEWER KEYMAP
# In the example, only the settings COLOR, VIEWER and KEYMAP are accepted by
# lynx.  Other settings are ignored.  Note:  INCLUDE is also treated as a
# setting, so to allow an included file to include other files, put INCLUDE in
# the list of allowed settings.
#
# If you allow an included file to include other files, and if a list of
# allowed settings is specified for that file with the INCLUDE command, nested
# files are only allowed to include the list of settings that is the set AND of
# settings allowed for the included file and settings allowed by nested INCLUDE
# commands.  In short, there is no security hole introduced by including a
# user-defined configuration file if the original list of allowed settings is
# secure.

jede Menge Kommentar, was will man mehr?

und einfach zu parsen ist es auch, so what?

[jemand aus dem wald]

THX 1138 schrieb:

Section "Screen"
Identifier "Default Screen"
Device "Geforce"
Monitor "iiyama ProLite E1900S"
DefaultDepth 24
SubSection "Display"
Depth 24
Modes "1280x1024" "1280x960" "1152x864" "1024x768" "800x600" "640x480"
EndSubSection
EndSection

Na, also das geht ja gar nicht, denn da ist viel zu viel Balast dabei, der nur das menschliche Auge unterstützen soll. Ich denke dabei an diese ganzen EndSections, etc..

[THX 1138]

ja, echt die luxus variante

[DEvent]

Blue-Tiger schrieb:

Hmmmm... Also wie ein INI-File auszusehen hat weiss wohl jeder, dazu brauchts ja dann wohl keinen Standard Im Gegensatz zu XML, was kompliziert (sprich: umfangreich) genug ist um einen Standard zu brauchen. Wenn ich's mir aussuchen koennt, wo ich als Benutzer lieber rumfrickel, dann definitiv in INI-Files. Your mileage may vary.

Ja das war mein Punkt.
Muss er jetzt, aus irgendeinem Grund, eine andere Lib einsetzen, die INI-Files liest/schreibt, dann muss er seine Config-Datei neu schreiben.

[megatroll]

hätte ich das nur früher gewusst, dass XML fast besser geht als Java

[darthdespotism]

THX 1138 schrieb:

Oh my god (musst ich jetzt einfach mal sagen)

Wo ist euer Problem? Er will Konfigurationen speichern

Section "Screen"
    Identifier     "Default Screen"
    Device         "Geforce"
    Monitor        "iiyama ProLite E1900S"
    DefaultDepth    24
    SubSection     "Display"
        Depth       24
        Modes      "1280x1024" "1280x960" "1152x864" "1024x768" "800x600" "640x480"
    EndSubSection
EndSection

Selbsterklärend und "human-readable" *bingo*

Und was ist da jetzt das Problem stat Section ... EndSection da <> rum zu machen

<screen>
    <Identifier value="Default Screen"/>
    <Device value="Geforce"/>
    <Monitor value="iiyama ProLite E1900S"/>
    <DefaultDepth value=24/>
    <display>
        <Depth value=24/>
        <Modes value="1280x1024 | 1280x960 | 1152x864 | 1024x768 | 800x600 | 640x480"/> 
    </display>
<screen>

Und das könnte man dann bestimmt noch anpassen

[DEvent]

@darthdespotism
argh, Daten in den Attributen?? Seit wann sind die Daten worauf des ankommt Metadaten? Vor allem bei Modes ist es sowas von falsch.

<display>
    <depth>24</depth>
    <modes>
        <mode>1280x1024</mode>
        <mode>1280x960</mode>
        <mode>1152x864</mode>
        <mode>1024x768</mode>
        <mode>800x600</mode>
        <mode>640x480</mode>
    </modes>
</display>

[minhen]

rüdiger schrieb:

@minhen
Warum ist YAML die einzige alternative? Warum fährt man "sicherer" mit XML? Welche Infrastruktur meinst du?

Na schau dir doch mal die von dir genannten Alternativen an. Bei XML habe ich XML als Kern-Technologie, die einfach zu implementieren und gut zu handhaben ist. Wie ich eben am Beispiel der Namensräume auch erst ausgeführt habe, führen die zusätzlichen Möglichkeiten bei XML keinesfalls zu Einschränkungen der Interoperabilität wie du behauptest. Man hat einfach nur im Bezug auf Interoperabilität besonders durchdachte zusätzliche Möglichkeiten. Und für ein und die selbe Sache gibt es entgegen deiner Behauptung auch nicht verschiedene Spezifikationen. Aber es gibt gut ausgearbeitete Spezifikationen. Daran scheitern schon die meisten deiner "Alternativen". Ganz davon abgesehen, dass YAML, OGDL, noch nicht einmal stabile und finale Spezifikationen besitzen. Die Spezifikation von XML ist schon seit Jahren endgültig und entsprechend gut umgesetzt und verbreitet. Was du über XML sagst ist durch deine Alternativen geradezu absurd. Im Gegensatz zu diesen ist XML auch ein endgültiger, internationaler Standard. Das garantiert dir dann doch deutlich mehr Zukunftssicherheit als das, was eine Mailing-List als Arbeitsentwurf für eine Spezifikation (-> YAML) zusammengeschustert hat.
Von der Infrastruktur will ich eigentlich gar nicht erst anfangen. Wenn ich mag, kann ich XML-Dateien beliebig bündeln und zusammenwürfeln (Namensräume), ich kann XML-Dokumente von einem Format in ein anderes transformieren (XSLT), ich kann ihnen eine eigenständige optische Erscheinung geben (CSS, XSL-FO), ich kann eindeutige Verweise auf sehr einfache Weise innerhalb der Dokumente verwenden (id, xml:id), ich kann auch eindeutige Verweise auf externe Dokumente setzen (XLink), ich kann bestimmte Bereiche der Dokumente adressieren (XPath), ich kann große XML-Dokumente als Datenbank sehen (XQuery), ich kann die Struktur von XML-Dokumenten eindeutig definieren - für Konfigurationsdateien ist hier auch die Definition von Default-Werten ziemlich interessant - (DTD, XML Schema) und vor allem kann ich XML-Dokumente als Objekte in meinen Programmen verwenden (DOM).
All diese Technologien sind zusätzliche Möglichkeiten. Die Kerntechnologie XML wird dadurch in keinster Weise eingeschränkt. Ich kann diese Möglichkeiten nutzen, wenn sie mir sinnvoll erscheinen, und ich kann sie schlicht ignorieren und nicht verwenden wenn ich sie nicht brauche. Das gilt sowohl für die reine Anwenderseite als auch für das Entwickeln von Parsern. Ein Parser muss keine der genannten zusätzlichen Techniken unterstützen. Einzige Ausnahmen sind ein Teil der DTDs und die IDs, welche zum XML-Kern gehören. Wie am Beispiel der Namensräume schon ausgeführt, die zusätzlichen Möglichkeiten zerstören in keinster Weise die Interoperabilität als XML. Wie ebenfalls schon gesagt: der Kram ist eben gut durchdacht. Und zwar auch so weit, dass die jeweiligen Spezifikationen die Bereich sehr gut definieren. Die Sachen sind absolut eindeutig definiert. Da gibt's keine Unsicherheiten und kein Rätselraten. Die XML-Spezifikation gibt sogar Algorithmen an, die ich als Parserbauer nur abzutippen brauche.
Wie sieht's bei deinen "Alternativen" aus? Sind die ebenfalls so durchdacht und wohl definiert? Sind sie ebenfalls so offen und erweiterbar, was die Möglichkeiten angeht? (Antwort ist beide Male nein, hab mir die Spezifikationen angesehen)

Das ist aber noch nicht einmal das, was ich mit Infrastruktur meine. XML ist purer Text, im schlimmsten Fall reicht also ein billig einfacher Texteditor bereits für die Arbeit mit XML aus. Im weniger schlimmen Fall ein moderner Browser. XML, DOM, XSLT, XPath, CSS wird zum Beispiel von diesen Browsern unterstützt. Natürlich gibt es noch unzählige weitere Programme und Editoren für die Arbeit mit XML. Infrastruktur eben. Aber auch ganz normale Programme arbeiten mit XML ob es jetzt ein Microsoft Word oder meine MySQL-Datenbank ist, beide exportieren und importieren vergnügt XML. Solche Dinge machen einem das Leben natürlich schon angenehmer. Das wichtigste Argument für einen Entwickler dürfte aber die Unterstützung bei der Programmiersprache seiner Wahl sein. Und da ist XML eben auch unschlagbar. Parser für XML gibt es unzählige, einige davon auch mit Unterstützung der anfangs genannten zusätzlichen Möglichkeiten. Ein internationaler Standard eben. Von einer solchen Unterstützung wie ich es bei der Entwicklung von XML von allen Seiten bekomme, kann man bei deinen Alternativen nur träumen. Bei denen ist es bereits ein absoluter Glücksfall, wenn es überhaupt einen Parser für die gewünschte Sprache gibt.

THX 1138 schrieb:

und einfach zu parsen ist es auch, so what?

Erstens mal werden die wenigsten einen Parser schreiben wollen, zweitens ist das keine INI-Datei und drittens ist es nicht einfacher zu parsen als XML. Einfaches Beispiel:
Bei XML hab ich bei Knoten immer Tags als Begrenzung (</?[^>]+>) und bei Attributen immer doppelte Hochkommata als Begrenzung ("[^"]+"). (Die regulären Ausdrücke nicht als echten XML-Parser verstehen sondern als einfachste Möglichkeit ranzukommen.) Bei der Beispiel-Konfigurationsdatei dagegen ist einmal ein doppeltes Hochkomma die Begrenzung und einmal, bei Zahlen, gibt es überhaupt keine Begrenzung. Einfach sieht für mich anders aus und bedeutet keine Extrafälle bei Begrenzungen und erst recht keine Extrafälle die auch noch vom Inhalt des zu begrenzenden abhängen. Sowas ist doch schrecklich.

Bisher habe ich mich ja überhaupt nicht zum Thema Konfigurationsdateien geäußert, da ich INI auch für die bessere Wahl hielt, sofern man nicht schon einen XML-Parser an Bord hat. Aber je mehr die INI-Verteidiger hier sagen, desto offensichtlicher wird, dass auch als Konfigurationsdatei XML eine bessere Wahl ist. Sei es die Beliebigkeit, nicht-Standardisierung von INI, die fehlende Möglichkeit für Standard-Werte oder Sonderfälle beim Parsen. Bei XML habe ich diese Probleme nicht und stattdessen volle Unterstützung seitens der "Infrastruktur".
Gratulation! Anfangs war ich ja, wie gesagt, gar nicht der Meinung, dass XML besser geeignet sei und habe nur dem Unsinn, der im Zusammenhang mit XML hier verzapft wird, widersprochen. Aber jetzt habt ihr mich davon überzeugt, dass XML auch bei Konfigurationen die bessere Wahl ist

[klofrau2]

Anmerkung: bei xml kannst du auch einfache hochkommata als attributbegrenzer benutzen (aber nicht mischen). sonst stimmt natürlich alles

[c.rackwitz]

'(screen (identifier "Default Screen")
         (device "Geforce")
         (monitor "iiyama ProLite E1900S")
         (defaultdepth 24)
         (display (depth 24)
                  (modes (1280 1024)
                         (1280 960)
                         (1152 864)
                         (1024 768)
                         (800 600)
                         (640 480))))

http://steve.yegge.googlepages.com/the-emacs-problem

[Artchi]

Hem, ich würde heute keines von beiden (ini oder xml) benutzen. Sondern würde auf eine Scriptsprache wie lua zugreifen. Die ist ideal dafür und ursprünglich sogar dafür entwickelt worden. ini und xml sind in meinen Augen bzgl. Configurationsleistungen (also was sie effektiv können) gleichwertig. Wobei ich xml für Config überhaupt nicht verstehen kann. Es ist nur formal "besser". xml halte ich für Datenaustausch zwischen unterschiedlichen Systemen und Anwendungen für sehr nützlich, mehr auch nicht.

Jedenfalls könnte man mit lua in der Config-Datei auch Bedingungen u.ä. einbauen. Z.B. wenn eine bestimmte Bildschirmauflösung nicht vorhanden ist, wird eine andere gewählt. Sowas müsste man ohne scriptsprache im C++-Programm vorhersehen bzw. einbauen. Die Möglichkeiten der Configuration würden auch autom. steigen. Bei XML und INI ist es immer stur, der Anwender kann eigentlich nichts viel bewirken, außer Attribute ändern. Einen Wirklichen Einfluss hat er mit beiden nicht. Deshalb halte ich die Diskussion Ini vs XML für akademisch.