À quel moment un fichier de configuration devient-il un langage de programmation?

Question

J'ai été ressassant des fichiers de configuration et de leur relation à code pour un certain temps maintenant, et en fonction du jour et de la direction du vent mes opinions semblent changer. De plus en plus et si je reviens à la réalisation que j'ai d'abord eu lors de l'apprentissage de Lisp: il y a peu de différence entre les données et le code. Cela semble d'autant plus vrai pour les fichiers de config. Quand on les regarde dans la bonne lumière un script Perl est un peu plus d'un fichier de configuration de perl. Cela a assez lourd de conséquences pour des tâches telles que la QA et de divisions du travail qui devrait être responsable de la modification des fichiers de configuration.

Le fluage de fichier de config à part entière de la langue est généralement lente et semble être dicté par le désir d'avoir un système générique. La plupart des projets semblent commencer petit avec un peu de config éléments comme le lieu d'écrire des journaux, où chercher les données, les noms d'utilisateur et mots de passe, etc. Mais ensuite, ils commencent à se développer: caractéristiques de démarrage pour être en mesure d'être allumé ou éteint, les horaires et l'ordre des opérations de commencer à être contrôlés, et, inévitablement, quelqu'un veut commencer à ajouter de la logique (par exemple, utilisation 10 si la machine est X et 15 si la machine est Y). À un certain point, le fichier de configuration devient un langage spécifique au domaine, et un mal écrit.

Maintenant que j'ai divaguait sur la scène, voici mes questions:

1. Quel est le vrai but de la config fichier?
2. Si une tentative est faite pour garder les les fichiers de configuration simple?
3. Qui devrait être chargé de faire des modifications (développeurs, utilisateurs, admins, etc.)?
4. Devraient-ils être source contrôlée (voir question 3)?

Comme je l'ai dit plus tôt, mes réponses à ces questions maj constamment, mais pour l'instant je pense:

1. afin de permettre à un non-programmeurs de changement de gros morceaux de comportement rapidement
2. oui, tout ce qui n'est pas grossièrement grain doit être dans le code
3. les utilisateurs devraient être responsables de la les fichiers de configuration et les programmeurs doivent être responsable d'une configuration couche entre les fichiers de configuration et de code qui donne plus de contrôle de précision de l'application
4. non, mais la plus fine couche du milieu devrait être

Answer 1

Questions très intéressantes!

J'ai tendance à limiter mes fichiers de config pour un très simple "clé=valeur", format, parce que je suis entièrement d'accord avec vous que les fichiers de configuration peuvent très rapidement devenir à part entière des programmes. Par exemple, quelqu'un qui a déjà essayé de "configurer" OpenSER sait le sentiment dont vous parlez: c'est pas de la configuration de la (douloureuse) de programmation.

Lorsque vous avez besoin que votre demande soit très "configurable" d'une manière que vous ne pouvez l'imaginer aujourd'hui, alors que vous avez vraiment besoin est un système de plugins. Vous avez besoin de développer votre application de sorte que quelqu'un d'autre le code d'un nouveau plugin et de le raccorder à votre demande dans l'avenir.

Donc, pour répondre à vos questions:

1. Quel est le vrai but d'un fichier de config?

   Je dirais, pour permettre aux gens qui vous permettront d'installer votre application pour être en mesure à l'ajustez certains liées au déploiement des paramètres, tels que le nom d'hôte, le nombre de threads, les noms des plugins dont vous avez besoin, et le déploiement des paramètres pour ces plugins (vérifiez la configuration de FreeRadius pour un exemple de ce principe), etc.. Certainement pas le lieu pour exprimer la logique d'entreprise.

2. Si une tentative est faite pour garder les fichiers de configuration simple?

   Certainement. Comme vous l'avez suggéré, "programmation" dans un fichier de config est horrible. Je crois qu'il devrait être évitée.

3. Qui devrait être chargé de faire des modifications (développeurs, utilisateurs, administrateurs, etc.)?

   En général, je dirais que les admins qui le déploiement de l'application.

4. Devraient-ils être source contrôlée (voir question 3)?

   J'ai l'habitude de ne pas la source de contrôle de la configuration des fichiers eux-mêmes, mais je ne le contrôle des sources d'un modèle de fichier de configuration, avec tous les paramètres et leurs valeurs par défaut, et des commentaires décrivant ce qu'ils font. Par exemple, si un fichier de configuration nommé database.conf, j'ai l'habitude de contrôle des sources d'un fichier nommé database.conf.template. Maintenant, bien sûr, je parle de ce que je fais en tant que développeur. En tant qu'administrateur, vous souhaitez peut-être à la source de contrôle les paramètres réels que j'ai choisi pour chaque installation. Par exemple, nous gérons à quelques centaines de serveurs à distance, et nous avons besoin de garder une trace de leurs configurations: nous avons choisi de le faire avec la commande source.

---

Edit: Même si je crois que le ci-dessus pour être vrai pour la plupart des applications, il y a toujours des exceptions, bien sûr. Votre application peut permettre à ses utilisateurs de configurer dynamiquement des règles complexes, par exemple. La plupart des clients de messagerie permet aux utilisateurs de définir des règles pour la gestion de leurs e-mails (par exemple, "tous les mails en provenance de" john doe "et de ne pas m'avoir dans: le champ doit être jeté"). Un autre exemple est une application qui permet à l'utilisateur de définir un nouveau complexe offre commerciale. Vous pouvez aussi penser à des applications comme Cognos qui permettent à leurs utilisateurs de créer des complexes de rapports de base de données. Le client de messagerie ne sera probablement offrir à l'utilisateur une interface simple à définir les règles du jeu, et cela va générer un complexe fichier de configuration (ou peut-être même un peu de code). D'autre part, les configurations définies par l'utilisateur pour les offres commerciales peut être enregistré dans une base de données, de façon structurée (ni d'une simple clé=valeur de la structure, ni d'une portion de code). Et d'autres applications peuvent même permettre à l'utilisateur de code en python ou VB, ou certains autres automatisables langue. En d'autres mots... votre kilométrage peut varier.

Answer 2

Ok. Vous avez des utilisateurs qui veulent vraiment une simple config, vous devriez leur donner. Dans le même temps, vous aurez des demandes constantes de "Pouvez-vous ajouter? Comment dois-je faire dans le fichier de config?", Je ne vois pas pourquoi vous ne pouvez pas supporter les deux groupes.

Le projet que je suis en train de travailler sur utilise Lua pour son fichier de configuration. Lua est un langage de script, et il fonctionne très bien dans ce scénario. Il est disponible un exemple de notre configuration par défaut.

Vous remarquerez qu'il est principalement clé=valeur, de déclarations, d'où la valeur peut être n'importe quel de Lua de type intégré. Le plus compliqué il y a des listes, et ils ne sont pas vraiment compliqué (c'est juste une question de syntaxe).

Maintenant je suis en attente pour quelqu'un de se demander comment définir leur port du serveur à une valeur aléatoire à chaque fois qu'ils le démarrer...

Answer 3

Récemment, je travaillais sur un projet et j'ai réalisé que je voulais avoir des conditions à l'intérieur de mon fichier de configuration, - qui avait déjà tout juste d'être assez simple de la forme:

key = val
key2 = val
name = `hostname`

Je n'ai pas envie d'écrire un mini-langage, parce que si j'ai fait très attention je ne pouvais pas permettre la flexibilité qui serait utile.

Au lieu de cela, j'ai décidé que j'en aurais deux formes:

1. Si le fichier a commencé avec "#!" et est exécutable que j'avais analyser le résultat de l'exécution.

2. Sinon j'avais lu comme ça

Cela signifie que je peux maintenant permettre aux gens d'écrire "fichiers de configuration" qui ressemblent à ceci:

 #!/usr/bin/perl
if ( -x /bin/foo ) 
{
   print <<EOF;
foo=me
bar=you
EOF
}
else
{
   print <<EOF;
foo=bar
bar=foo
EOF
}

De cette façon, je reçois la puissance d'une dynamique de fichier de configuration si l'utilisateur souhaite l'utiliser, et la simplicité de ne pas avoir à écrire mon propre mini-langage.

Answer 4

Chaque schéma de fichier de configuration (de durée de vie suffisante) finit par devenir un langage de programmation. En raison de toutes les implications que vous décrivez, il est sage que le concepteur de fichier de configuration réalise qu'il est en train de créer un langage de programmation et de planifier en conséquence, de peur de surcharger les futurs utilisateurs avec un mauvais héritage.

Answer 5

J'ai une philosophie différente sur les fichiers de configuration. Les données sur la manière dont une application doit être exécutée sont toujours des données et appartiennent donc à un magasin de données, pas à du code (un fichier de configuration IMO est un code). Si les utilisateurs finaux doivent pouvoir modifier les données, l’application doit fournir une interface pour le faire.

J'utilise uniquement les fichiers de configuration pour pointer vers les magasins de données.