XML pour les fichiers de configuration, pourquoi?
Pourquoi autant de projets utilisent XML pour les fichiers de configuration?
Merci pour vos réponses… .. Cette question, aussi naïve que cela puisse paraître à première vue, n'était pas si naïve :)
Personnellement, je n'aime pas le XML pour les fichiers de configuration, je pense que les gens ont du mal à lire et à changer, et que les ordinateurs ont du mal à analyser car ils sont tellement génériques et puissants.
Les fichiers INI ou les fichiers de propriétés Java conviennent uniquement aux applications les plus élémentaires nécessitant une imbrication. Les solutions courantes pour ajouter une imbrication à ces formats se présentent comme suit:
level1.key1=value
level1.key2=value
level2.key1=value
pas une belle vue, beaucoup de redondance et difficile de déplacer les choses entre les nœuds.
JSON n'est pas un mauvais langage, mais il est conçu pour être facilement analysé par les ordinateurs (c'est du JavaScript valide), il n'est donc pas utilisé de manière sauvage pour les fichiers de configuration.
JSON ressemble à ceci:
{"menu": {
"id": "file",
"value": "File",
"popup": {
"menuitem": [
{"value": "New", "onclick": "CreateNewDoc()"},
{"value": "Open", "onclick": "OpenDoc()"},
{"value": "Close", "onclick": "CloseDoc()"}
]
}
}}
À mon avis, il est trop encombré de virgules et de citations.
YAML est bon pour les fichiers de configuration, voici un exemple:
invoice: 34843
date : 2001-01-23
bill-to: &id001
given : Chris
family : Dumars
cependant, je n'aime pas trop sa syntaxe, et je pense que l'utilisation de l'espace pour définir les portées rend les choses un peu fragiles (pensez à coller un bloc à un niveau d'imbrication différent).
Il y a quelques jours, j'ai commencé à écrire ma propre langue pour le fichier de configuration, je l'ai surnommé Swush .
Voici quelques exemples: Sous forme de simples paires clé-valeur:
key:value
key:value2
key1:value3
ou plus complexe et commenté
server{
connector{
protocol : http // HTTP or BlahTP
port : 8080 # server port
Host : localhost /* server Host name*/
}
log{
output{
file : /var/log/server.log
format : %t%s
}
}
}
Swush prend en charge les chaînes sous la forme simple ci-dessus, ou entre guillemets, ce qui permet d'utiliser des espaces et même des sauts de ligne à l'intérieur des chaînes . Je vais bientôt ajouter des tableaux, tels que:
name [1 2 b c "Delta force"]
Il existe une implémentation Java, mais d'autres implémentations sont les bienvenues. :) . consultez le site pour plus d’informations (j’en ai couvert la majeure partie, mais l’API Java fournit quelques fonctionnalités intéressantes comme des sélecteurs)
Ceci est une question importante.
La plupart des alternatives (fichiers JSON, YAML, INI) sont plus faciles à analyser que XML.
De plus, dans des langages tels que Python - où tout est source - il est plus facile de simplement placer votre configuration dans un module Python clairement étiqueté.
Pourtant, certaines personnes diront que XML a un avantage sur JSON ou Python.
Ce qui est important avec XML, c’est que «l’universalité» de la syntaxe XML ne s’applique pas beaucoup lors de l’écriture d’un fichier de configuration spécifique à une application. Comme la portabilité d'un fichier de configuration n'a pas d'importance, certains utilisateurs Python écrivent leurs fichiers de configuration en Python.
Modifier
La sécurité d'un fichier de configuration n'a pas d'importance. L'argument "La configuration d'un programme Python dans Python est un risque pour la sécurité" semble ignorer le fait que Python est déjà installé et s'exécute en tant que source. Pourquoi travailler un hack complexe dans un fichier de configuration quand vous avez le source? Il suffit de pirater la source.
J'ai entendu des gens dire que "quelqu'un" pourrait pirater votre application via le fichier de configuration. Qui est ce "quelqu'un"? L'administrateur système? Le DBA? Le développeur? Il n’ya pas beaucoup de "personnes" mystérieuses ayant accès aux fichiers de configuration.
Et quiconque pourrait pirater le fichier de configuration Python à des fins néfastes pourrait probablement installer des enregistreurs de frappe, de faux certificats ou d'autres menaces plus graves.
- XML est facile à analyser. Il existe plusieurs bibliothèques d'analyse XML populaires, légères, dotées de fonctionnalités et/ou gratuites, disponibles dans la plupart des langues.
- XML est facile à lire. C'est un langage de balisage très lisible par l'homme, il est donc facile à écrire et à l'ordinateur à écrire.
- XML est bien spécifié. Tout le monde et son chien savent comment écrire du code XML correct, il n’ya donc aucune confusion quant à la syntaxe.
- XML est populaire. À un moment donné, certaines personnalités importantes ™ ont commencé à promouvoir l'idée que XML était "l'avenir" et beaucoup l'ont acheté.
- XML est un format bidirectionnel. C'est-à-dire que les espaces, les commentaires et l'ordre sont préservés. Vous pouvez le charger, le modifier et le sauvegarder par programme tout en préservant le formatage. Ceci est important pour les outils que les utilisateurs peuvent utiliser pour configurer leurs applications. C’est l’une des raisons pour lesquelles XML a pris son essor (le monde est devenu plus technique, ce qui est moins nécessaire).
- XML dispose d'une validation de schéma facultative. Important pour les outils et les formats de configuration complexes.
- XML a des espaces de noms. Cela permet d’intégrer d’autres configurations ou annotations sans effectuer l’analyse. Dans les autres formats de configuration, cela se fait généralement sous forme de commentaires spéciaux ou de nom de propriété.
En passant, je ne cherche pas à défendre XML. Il a ses utilisations et je l'utiliserai dans un projet chaque fois que j'y reviendrai. Cependant, dans de nombreux cas, et en particulier dans les fichiers de configuration, le seul avantage est qu’il s’agit d’un format normalisé, ce qui est largement compensé par de nombreux inconvénients (par exemple, il est trop détaillé). Cependant, mes préférences personnelles importent peu - je voulais simplement savoir pourquoi certaines personnes pourraient choisir d'utiliser XML comme format de fichier de configuration. Personnellement, je ne le ferai jamais.
Parce que XML semble cool et d'entreprise.
Edit: Je n’avais pas réalisé que ma réponse était si vague, jusqu’à ce qu’un intervenant demande la définition de enterprisey. Citer Wikipedia :
[...] le terme "entreprise" vise à aller au-delà de la préoccupation "d'overkill pour les petites organisations", ce qui implique que le logiciel est trop complexe, même pour les grandes entreprises, et qu'il existe des solutions simples et éprouvées.
Ce que je veux dire, c'est que XML est un mot à la mode et, en tant que tel, est surexploité. Malgré d’autres opinions, XML n’est pas facile à analyser (il suffit de regarder libxml2, son paquet source gzippé dépasse actuellement 3 Mo). En raison de la quantité de redondance, il est également gênant d’écrire à la main. Par exemple, Wikipedia répertorie la configuration XML comme l’une des raisons de la baisse de popularité de jabberd au profit d’autres implémentations.
XML est un standard bien développé et adopté, le rendant plus facile à lire et à comprendre que les formats de configuration propriétaires.
De plus, il est utile de comprendre que la sérialisation XML est un outil commun disponible dans la plupart des langages, ce qui facilite extrêmement la sauvegarde des données d'objet pour les développeurs. Pourquoi créer votre propre façon de sauvegarder une hiérarchie de données complexes alors que quelqu'un d'autre a déjà fait le travail pour vous?
.NET: http://msdn.Microsoft.com/en-us/library/system.xml.serialization.aspx
PHP: http://us.php.net/serialize
Python: http://docs.python.org/library/pickle.html
Java: http://Java.Sun.com/developer/technicalArticles/Programming/serialization/
Autre point, si vous avez un XSD (fichier de schéma) pour décrire votre fichier de configuration, il est facile pour votre application de valider le fichier de configuration.
L'analyse XML étant relativement facile et si votre schéma est clairement spécifié, tout utilitaire peut y lire et écrire facilement des informations.
Eh bien .., XML est une spécification polyvalente pouvant contenir des descriptions, des informations imbriquées et des données relatives à quelque chose. Et de nombreuses API et logiciels peuvent l’analyser et le lire.
Il est donc très facile de décrire de manière formelle quelque chose qui est connu sur plusieurs plates-formes et applications.
Voici quelques raisons historiques:
- Le W3C est passé des outils de construction en Perl à Java
- La fondation Apache est passée des outils de construction en Perl à Java
- Java a beaucoup de API XML
- La configuration peut donc être faite en Java
- La configuration via XML et les fichiers de propriétés est destinée aux développeurs non-Java
JTidy configuration vs tidy configuration en est un excellent exemple.
Une raison qui n’a pas été spécifiée dans d’autres réponses est Unicode/encodage de texte/vous le nommez. Besoin d'une ficelle chinoise dans le fichier? Aucun problème. Cela peut sembler trivial, mais ce n’était pas le cas lorsque XML a été introduit. Évidemment pas dans les fichiers INI.
Une autre chose - c’est la première chose qui nous a permis d’avoir des données structurées avec des listes, des dictionnaires ou tout ce que vous voulez, ce qui peut être traité par une machine et être édité par l’homme en même temps.
Cela a des inconvénients, mais que pouvez-vous utiliser d'autre? Yaml a fière allure, mais j'ai peur de l'introduire dans les projets sur lesquels je travaille, car je vois dans mon imagination tous ces problèmes de personnes qui placent un espace blanc au mauvais endroit ou qui fusionnent des outils qui ne les intéressent pas.
Le principal avantage de XML et la raison de sa popularité sont dus au fait qu’il est populaire dans le monde Java et que toutes les applications d’entreprise écrites en Java l’utilisent ainsi applications de l'entreprise.
Et jusqu'à présent, JSON et tous les autres formats ne sont pas aussi bien pris en charge par l'industrie, sauf dans les applications ajax. En outre, JSON ne dispose pas d'un langage de schéma ou d'une API d'analyse syntaxique définie comme XML.
Même si, grosso modo, JSON n'a pas besoin des tonnes de choses que xml a, du moins pas de la même manière, et je parle de services Web, quand je dis ça ...
C'est parce que XML vous permet de créer votre propre balisage sémantique, qui peut être lu par un analyseur syntaxique construit dans pratiquement toutes les langues. Un avantage supplémentaire est que le fichier de configuration écrit en XML peut être utilisé sur des projets dans lesquels vous utilisez deux langues ou plus. Si vous deviez créer un fichier de configuration où tout était défini comme des variables pour une langue spécifique, cela ne fonctionnerait évidemment que dans cette langue.