Au sujet de la complexité, les formats de fichiers de conf devraient avoir les plus simples possibles, parce que c'est commode de pouvoir les générer automatiquement lors de déploiement automatisés sur un parc de machine. Et lorsqu'un humain regarde le fichier de conf, c'est appréciable que ce soit possible d'en comprendre très rapidement la structure et d'avoir peu de doutes sur sa syntaxe, même s'il ne maîtrise pas l'applicatif. L'idéal est donc de prendre un standard de format de conf texte existant. Or un langage de programmation, c'est l'opposé complet d'un langage textuel simple de fichiers de conf. Ça crée tout de suite un ticket d'entrée plus cher puisqu'il faut comprendre ce nouveau language de conf en plus.
J'ajouterais que ça n'est pas une solution originale, parce qu'utiliser un language de programmation pour la conf, ça a déjà été testé dans plein de domaines (sites PHP, Chef, ...) et que c'est désormais un antipattern notoire. Oui, Configuration As Code, il ne faut pas le prendre littéralement ;-)
En suite au sujet des bienfaits de Dhall, sur la validation, c'est bien, mais en vrai on s'en fiche dans la plupart des cas. Pour les formats de conf standards, les parseurs pas trop stupides savent déjà éliminer les erreurs syntaxiques, qui sont honnêtement pas celles qui vont arriver en prod le plus souvent. Le cœur du problème, ce qui coûte cher, ce sont les erreurs de format, de type et fonctionnelles, mais je ne vois pas du tout en quoi Dhall aide pour résoudre ce problème. Je pense que Dhall résoud des problèmes qui certes existent, mais avec des confs tellement complexes que leur fonctionnel mérite de s'interroger sur leur pertinence.
[^] # Re: Où est l'intérêt ?
Posté par damaki . En réponse au journal Dhall, une réponse au problème de configuration. Évalué à 4.
Au sujet de la complexité, les formats de fichiers de conf devraient avoir les plus simples possibles, parce que c'est commode de pouvoir les générer automatiquement lors de déploiement automatisés sur un parc de machine. Et lorsqu'un humain regarde le fichier de conf, c'est appréciable que ce soit possible d'en comprendre très rapidement la structure et d'avoir peu de doutes sur sa syntaxe, même s'il ne maîtrise pas l'applicatif. L'idéal est donc de prendre un standard de format de conf texte existant. Or un langage de programmation, c'est l'opposé complet d'un langage textuel simple de fichiers de conf. Ça crée tout de suite un ticket d'entrée plus cher puisqu'il faut comprendre ce nouveau language de conf en plus.
J'ajouterais que ça n'est pas une solution originale, parce qu'utiliser un language de programmation pour la conf, ça a déjà été testé dans plein de domaines (sites PHP, Chef, ...) et que c'est désormais un antipattern notoire. Oui, Configuration As Code, il ne faut pas le prendre littéralement ;-)
En suite au sujet des bienfaits de Dhall, sur la validation, c'est bien, mais en vrai on s'en fiche dans la plupart des cas. Pour les formats de conf standards, les parseurs pas trop stupides savent déjà éliminer les erreurs syntaxiques, qui sont honnêtement pas celles qui vont arriver en prod le plus souvent. Le cœur du problème, ce qui coûte cher, ce sont les erreurs de format, de type et fonctionnelles, mais je ne vois pas du tout en quoi Dhall aide pour résoudre ce problème. Je pense que Dhall résoud des problèmes qui certes existent, mais avec des confs tellement complexes que leur fonctionnel mérite de s'interroger sur leur pertinence.