XML pour les fichiers de configuration, pourquoi?

Pourquoi tant de projets utilisent-ils XML pour les fichiers de configuration?

Ceci est une question importante.

La plupart des alternatives (fichiers JSON, YAML, INI) sont plus faciles à parsingr que XML.

En outre, dans des langages comme 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 certains avantages 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 lors de l’écriture d’un fichier de configuration spécifique à une application. La portabilité d’un fichier de configuration étant sans importance, certains utilisateurs de Python écrivent leurs fichiers de configuration en Python.


modifier

La 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 sur un hack complexe dans un fichier de configuration lorsque vous en avez la source? Juste pirater la source.

J’ai entendu des gens dire que “quelqu’un” pouvait pirater votre application via le fichier de configuration. Qui est ce “quelqu’un”? L’administrateur système? Le DBA? Le développeur? Il n’y a pas beaucoup de “quelqu’un” mystérieux ayant access aux fichiers de configuration.

Et quiconque pourrait pirater le fichier de configuration Python à des fins malveillantes pourrait probablement installer des enregistreurs de frappe, de faux certificates ou d’autres menaces plus graves.

  1. XML est facile à parsingr. Il existe plusieurs bibliothèques d’parsing XML populaires, légères, fonctionnelles et / ou gratuites disponibles dans la plupart des langues.
  2. 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 aussi bien que pour les ordinateurs d’écrire.
  3. XML est bien spécifié. Tout le monde et son chien savent comment écrire du XML décent, il n’y a donc pas de confusion sur la syntaxe.
  4. XML est populaire. En cours de route, certaines personnes importantes ont commencé à pousser l’idée que le XML était «l’avenir» et que beaucoup de gens l’achetaient.
  5. XML est un format bidirectionnel. C’est à dire que les espaces, les commentaires et l’ordre sont préservés. Vous pouvez charger, modifier et enregistrer le programme par programmation tout en conservant la mise en forme. 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 envol (le monde est devenu plus technique, ce qui est moins nécessaire).
  6. XML a la validation de schéma facultative. Important pour les outils et formats de configuration complexes.
  7. XML a des espaces de noms. Cela permet d’incorporer d’autres configurations ou annotations sans effectuer l’parsing. Dans d’autres formats de configuration, cela se fait généralement avec des commentaires spéciaux ou un nom de propriété.

En passant, je n’essaie pas de défendre XML. Il a ses utilisations, et je vais l’utiliser dans un projet chaque fois que j’y reviens. Cependant, dans de nombreux cas, et en particulier les fichiers de configuration, le seul avantage est qu’il s’agit d’un format standardisé, et je pense que cela est largement compensé par de nombreux inconvénients (c’est-à-dire trop verbeux). Cependant, mes préférences personnelles n’ont pas d’importance – je répondais simplement à la question de savoir pourquoi certaines personnes pourraient choisir d’utiliser XML comme format de fichier de configuration. Personnellement, je ne le ferai jamais.

Parce que XML a l’air cool et d’entreprise.

Edit: Je n’ai pas réalisé que ma réponse était trop vague, jusqu’à ce qu’un commentateur demande la définition de enterprisey . Citation de Wikipedia :

[…] le terme “enterprisey” est destiné à aller au-delà du souci de “surpasser pour les petites organisations”, pour impliquer que le logiciel est trop complexe, même pour les grandes organisations et que des solutions plus simples et éprouvées sont disponibles.

Ce que je veux dire, c’est que XML est un mot à la mode et que, en tant que tel, il est surutilisé. Malgré d’autres opinions, XML n’est pas facile à parsingr (il suffit de regarder libxml2, son paquet source gzippé est actuellement supérieur à 3 Mo). En raison de la quantité de redondance, il est également ennuyeux d’écrire à la main. Par exemple, Wikipedia présente la configuration XML comme l’une des raisons de la baisse de popularité de jabberd au profit d’autres implémentations.

XML est une norme bien développée et adoptée, ce qui la rend plus facile à lire et à comprendre que les formats de configuration propriétaires.

En outre, il est important de comprendre que la sérialisation XML est un outil commun disponible dans la plupart des langages, ce qui facilite grandement l’enregistrement des données d’object pour les développeurs. Pourquoi créer votre propre manière de sauvegarder une hiérarchie de données complexes lorsque 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/

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’parsingr parce que c’est générique et puissant.

Les fichiers INI ou Java ne conviennent que pour les applications les plus élémentaires nécessitant une imbrication. Les solutions courantes pour append une imbrication à ces formats ressemblent à ceci:

 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 facile à parsingr pour les ordinateurs (il s’agit d’un code JavaScript valide). Il n’est donc pas utilisé de manière extravagante 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 les scopes 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 baptisée Swush .

Voici quelques exemples: en tant que paires clé-valeur simples:

 key:value key:value2 key1:value3 

ou comme 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 autorise les espaces blancs et même les nouvelles lignes à l’intérieur des chaînes. Je vais bientôt append des tableaux, quelque chose comme:

 name [1 2 bc "Delta force"] 

Il existe une implémentation Java, mais d’autres implémentations sont les bienvenues. 🙂 vérifier le site pour plus d’informations (j’ai couvert la plupart, mais l’API Java fournit quelques fonctionnalités intéressantes comme les sélecteurs)

Un autre point, si vous avez un fichier XSD (fichier de schéma) pour décrire votre fichier de configuration, il est sortingvial que votre application valide le fichier de configuration.

Parce que l’parsing XML est relativement facile et que votre schéma est clairement spécifié, tout utilitaire peut lire et écrire facilement des informations.

Eh bien, XML est une spécification polyvalente qui peut contenir des descriptions, des informations nestedes et des données sur quelque chose. Et il existe de nombreuses API et logiciels qui peuvent l’parsingr et le lire.

Il est donc très facile de décrire de manière formelle des plates-formes et des applications connues.

Voici quelques raisons historiques:

  • Le W3C est passé de la création d’outils en Perl à Java
  • La fondation Apache est passée des outils de construction de Perl à Java
  • Java a beaucoup d’ 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

La configuration JTidy vs la configuration ordonnée en est un bon exemple.

C’est parce que XML vous permet de créer votre propre balisage sémantique, qui peut être lu par un parsingur construit dans pratiquement n’importe quel langage. 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 variable pour une langue spécifique, cela ne fonctionnerait évidemment que dans cette langue.

Le principal avantage de XML et la raison pour laquelle il est si populaire est qu’il est populaire dans le monde Java et que toutes les applications d’entreprise écrites en Java l’utilisent, et aussi parce que les services Web et le soap applications de l’entreprise.

Et jusqu’à présent, JSON et tous les autres formats ne sont pas aussi bien pris en charge par l’indussortinge, sauf dans les applications ajax. De plus, JSON n’a pas de langage de schéma ni d’API d’parsing syntaxique défini, tel que XML.

Même si, grosso modo, JSON n’a pas besoin de tonnes de choses, du moins pas de la même manière, et je parle dans les services Web, quand je dis ça …

L’une des raisons qui n’a pas été spécifiée dans d’autres réponses est le codage Unicode / text / vous le nommez. Besoin d’une ficelle chinoise dans le fichier? Aucun problème. Cela peut sembler sortingvial, mais ce n’est pas le cas avec XML. Evidemment pas dans les fichiers INI.

Autre chose: c’était la première chose qui nous donnait la possibilité d’avoir des données structurées avec des listes, des dictionnaires ou tout ce que vous vouliez, qui soit traitable par une machine et humainement modifiable en même temps.

Il a des inconvénients, mais que pourriez-vous utiliser d’autre? Yaml a fière allure, mais j’ai peur de le présenter dans des projets sur lesquels je travaille car je ne vois dans mon imagination que tous les problèmes avec des personnes qui placent un espace blanc au mauvais endroit ou qui fusionnent sans se soucier d’eux.