XML pour les fichiers de configuration, pourquoi?
Pourquoi tant de projets utilisent XML pour les fichiers de configuration?
12 réponses
C'est une question importante.
La plupart des alternatives (fichiers JSON, YAML, INI) sont plus faciles à analyser que XML.
Aussi, dans des langages comme Python-où tout est source - il est plus facile de simplement mettre 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 à propos de XML, c'est que "l'universalité" de la syntaxe XML ne s'applique pas vraiment 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 Python écrivent leurs fichiers de configuration en Python.
Modifier
Sécurité d'un fichier de configuration n'a pas d'importance. L'argument "configurer un programme Python en Python est un risque de sécurité" semble ignorer le fait que Python est déjà installé et exécuté en tant que source. Pourquoi travailler un hack complexe dans un fichier de configuration lorsque vous avez le source? Juste hack de 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"? Le sysadmin? Le DBA? Le développeur? Il n'y a pas beaucoup de "quelqu'un"mystérieux avec 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, fonctionnelles 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 pour les humains d'écrire ainsi que pour les ordinateurs d'écrire.
- XML est bien spécifié. Tout le monde et son chien savent comment écrire du XML décent, donc il n'y a pas de confusion sur la syntaxe.
- XML est populaire. Quelque part le long du chemin, certaines personnes importantes™ a commencé à pousser l'idée que XML était le "futur", et beaucoup de gens l'ont acheté.
- XML est un format bidirectionnel. C'est-à-dire que les espaces, les commentaires et l'ordre sont conservés. Vous pouvez le charger par programme, le modifier, puis l'enregistrer 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 décollé à l'origine (le monde est devenu plus technique, donc c'est moins nécessaire).
- XML a un schéma optionnel validation. 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 d'autres formats de configuration, cela se fait généralement comme un hack avec des commentaires spéciaux ou un nom de propriété mangling.
Comme note de côté, je n'essaie pas de défendre XML. Il a ses utilisations, et je l'utiliserai dans un projet chaque fois que je reviendrai à cela. Dans de nombreux cas, cependant, et surtout fichiers de configuration, le seul avantage qu'il a est que c'est un format standardisé, et je pense que cela est largement compensé par de nombreux inconvénients (c'est-à-dire que c'est trop verbeux). Cependant, mes préférences personnelles n'ont pas d'importance - je répondais simplement pourquoi certaines personnes pourraient choisir D'utiliser XML comme format de fichier de configuration. Personnellement, je ne le sera jamais.
Parce que XML semble cool et entrepreney.
Edit: Je n'ai pas réalisé que ma réponse était si vague, jusqu'à ce qu'un commentateur demande la définition de enterprisey. Citant Wikipedia:
[...] le terme "entrepreney" est destiné à aller au-delà de la préoccupation de "surcoût pour les petites organisations", pour impliquer que le logiciel est trop complexe, même pour les grandes organisations et des solutions plus simples et éprouvées sont disponibles.
Mon point est que XML est un mot à la mode et en tant que tel est surutilisé. Malgré d'autres opinions, XML n'est pas facile à analyser (il suffit de regarder libxml2, son paquet source gzippé est actuellement supérieur à 3MB). En raison de la quantité de redondance, il est aussi ennuyeux d'écrire à la main. Par exemple, listes de Wikipédia XML de configuration comme l'une des raisons de la diminution de la popularité de jabberd en faveur 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.
En outre, il vaut la peine de comprendre que la sérialisation XML est un outil commun disponible dans la plupart des langues qui rend l'enregistrement des données d'objet extrêmement facile pour les développeurs. Pourquoi construire votre propre façon de sauver une hiérarchie de données complexes lorsque quelqu'un l'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/
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 XML pour les fichiers de configuration, je pense qu'il est difficile pour les gens de lire et de changer, et il est difficile pour les ordinateurs d'analyser parce que c'est si générique et puissant.
Les fichiers INI ou les fichiers Java propery ne conviennent que pour les applications les plus basiques nécessitant une imbrication. les solutions courantes pour ajouter l'imbrication à ces formats ressemblent à:
level1.key1=value
level1.key2=value
level2.key1=value
Pas un jolie 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 facile à analyser par les ordinateurs (C'est du JavaScript valide), donc il n'est pas sauvagement utilisé 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, c'est trop encombré de virgules et de guillemets.
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 des espaces pour définir des étendues 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: en tant que paires clé-valeur simples:
key:value
key:value2
key1:value3
, Ou comme un 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 des espaces blancs et même des sauts de ligne à l'intérieur chaîne. Je vais bientôt ajouter des tableaux, quelque chose comme:
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'ai couvert la majeure partie, mais L'API Java fournit quelques fonctionnalités intéressantes comme les sélecteurs)
Un autre point, si vous avez un XSD (schema file) pour décrire votre fichier de configuration, il est trivial pour votre application de valider le fichier de configuration.
Parce que L'analyse XML est relativement facile, et si votre schéma est clairement spécifié, n'importe quel utilitaire peut lire et écrire des informations facilement.
Eh bien.., XML est une spécification à usage général qui peut contenir des descriptions, des informations imbriquées et des données sur quelque chose. Et il existe de nombreuses API et logiciels qui peuvent l'analyser et le lire.
Il est donc très facile de décrire quelque chose de manière formelle qui est connu entre les plates-formes et les applications.
Voici quelques raisons historiques:
- le W3C est passé des outils de construction en Perl à Java
- La Fondation Apache est passée de la création D'outils en Perl à Java
- Java a beaucoup d'API XML
- la Configuration peut donc se faire en Java
- Configuration via XML et fichiers de propriétés {[9] } est pour les développeurs Non-Java
JTidy configuration vs rangé configuration est un excellent exemple de cela.
C'est parce que XML vous permet de créer votre propre balisage sémantique, qui peut être lu par un analyseur construit dans pratiquement n'importe quelle langue. Un avantage supplémentaire est que le fichier de configuration écrit en XML peut être utilisé sur des projets où 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 que dans cette langue, évidemment.
Le principal avantage de XML et la raison pour laquelle il est si populaire est parce qu'il est populaire dans le monde java et donc toutes les applications d'entreprise écrites en java l'utilisent, et aussi parce que les services web et soap sont basés sur xml et ceux-ci sont beaucoup utilisés dans les applications d'entreprise.
Et jusqu'à présent, JSON et tous les autres formats ne sont pas si bien pris en charge par l'industrie, sauf dans les applications ajax. En outre, JSON n'a pas de langage de schéma ou d'api d'analyse 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 dans les services web, quand je dis cela...
Une raison qui n'a pas été spécifiée dans d'autres réponses est L'encodage Unicode / text / vous le nommez. Besoin d'une chaîne chinoise dans le fichier? Ce n'est rien. Cela peut sembler trivial, mais quand XML a été introduit, ce n'était pas le cas. évidemment pas dans les fichiers INI.
Une autre chose-c'est la première chose qui nous a donné la possibilité d'avoir des données structurées avec des listes, des dictionnaires ou tout ce que vous voulez, qui est à la fois traitable par la machine et modifiable par l'homme.
Il a des inconvénients, mais quoi pourriez-vous utiliser? Yaml a l'air génial, mais j'ai peur de l'introduire dans les projets sur lesquels je travaille parce que je vois dans mon imagination tous ces problèmes avec les gens qui mettent un espace blanc au mauvais endroit, ou qui fusionnent des outils qui ne s'en soucient pas.