Le Vendredi 22 Juillet 2005 15:47, Jean-Michel BESSOT a écrit : > Salut > > Jeasuis d'accord avec guiguilinux, xml permettra de faciliter le > boulot du codeur et du programme, mais on est une distro humaine et le > xml n'est pas très humainement compréhensible d'après moi.
Salut :-) Si vous trouvez que XML n'est pas humainement compréhensible, il semblerait logique que bash le soit encore moins :-) Les scripts shells utilisent bash comme langage de programmation, et les langages de programmation sont loin d'être compréhensibles par le commun des mortels. Ce sont surtout les programmeurs ont plus de facilités à ce niveau-là. XML à l'inverse n'est pas un langage de programmation mais un langage de description de contenu, dont l'un des objectifs cité dans la recommandation est "d'être humainement lisible et raisonnablement clair". Pour ce qui est de savoir si cet objectif est atteint ou non, à chacun son point de vue :-) Revenons à Ncooker et comparons les deux approches. Avec l'approche "bash", nous avons : NPKG_PRJ_VERSION='1.0' NPKG_PRJ_LICENSE='GPL' NPKG_PRJ_AUTHORS='me' NPKG_PRJ_COPYRIGHTS='none' NPKG_PRJ_HOME_URL='http://www.homepage.org/' NPKG_PRJ_SRC_URLS[0]='mirror://gnu/paquet-1.0-nga1.nbuild http://www.gnu.org/paquet-1.0-nga1.nbuild' NPKG_PRJ_SRC_URLS[1]='mirror://gnu/res-1.0-nga1.nbuild http://www.gnu.org/res-1.0-nga1.nbuild' avec l'approche XML, on a : <npkg> <project> <version>1.0</version> <license>GPL</license> <author>me</author> <copyright>none</copyright> <homepage>http://www.homepage.org/</homepage> <resources> <file name="paquet-1.0-nga1.nbuild"> <location>mirror://gnu</location> <location>http://www.gnu.org/</location> </file> <file name="res-1.0-nga1.nbuild"> <location>mirror://gnu</location> <location>http://www.gnu.org/</location> </file> </resources> </project> </npkg> Pour tester, j'ai montré ces deux exemples à une personne qui n'y connait absolument rien en packages. Je lui ai juste dit qu'il s'agissait d'informations sur une application, et lui ai demandé de me donner les infos qu'elle reconnaissait. Pour les variables "simples", ça va, bash reste compréhensible. Mais les abréviations utilisées dans les noms de variables ne sont pas évidentes à comprendre, notamment PRJ et SRC. On pourrait mettre les mots complets : on gagnerait en compréhension, mais le nom des variables serait plus long. Dès qu'on aborde le tableau d'URLs des archives sources, c'est le flou le plus total : aucune idée de ce que représente les chiffres en crochets. Et le fait d'indiquer 2 URLs pour chaque variable n'est pas compris. La personne pense qu'il y a l'adresse de quatre fichiers, mais ne sait pas à quoi ils correspondent. Lorsque j'ai montré l'exemple XML, la première impression a été que c'est plus clair, plus structuré. Le fait d'utiliser des mots complets au lieu d'abbréviation facilite la compréhension, de même que l'indentation. Les informations simples ont été là aussi reconnues facilement. L'utilisation de "file" permet de mieux comprendre qu'on parle de deux fichiers et non pas quatre, et qu'on indique l'emplacement de chacun. Je vous invite à faire ce test par vous-même auprès d'une personne de votre entourage :-) > je suis centre ce type d'approche : cela rend la creation de paquet moins aisée > et plus elitiste, Moins aisée, je ne trouve pas. Plus longue, à la rigueur (et encore, il suffit de fournir un fichier infos vide qu'il ne reste plus qu'à compléter). La syntaxe XML est simple, et s'apprend plus rapidement que celle du bash car il s'agit toujours de la même chose : une balise ouvrante + une info + une balise fermante. Avec bash, la syntaxe change selon qu'il s'agisse d'une simple variable ou d'un tableau. Si les variables simples sont plus rapides à écrire qu'en XML, les tableaux sont eux complexes et peuvent être source d'erreur (indices qui ne se suivent pas, par exemple). De plus, il faut faire attention à bien protéger les valeurs des variables avec des guillemets quand c'est nécessaire (valeur avec des espaces). Il faut être d'autant plus vigilant avec les tableaux pour lesquels l'espace sert aussi de séparateurs entre les valeurs. Avec XML, pas besoin de réfléchir à tout ça : on place la valeur entre les balises et c'est tout. On peut donc se concentrer sur les informations à fournir sans avoir à se soucier des "protections" à ajouter. > et ça conplecifie d'autant ncooker par rapport à des > siples fichiers bash Bien au contraie, ça simplifie grandement Ncooker et ça renforce sa sécurité. Pour la sécurité, le fichier infos étant un script shell, on pourrait très bien bien y mettre une commande "`rm -rf $HOME`" exécutée comme valeur de variable. Pour éviter ça, il faudrait transformer le fichier infos en simple fichier texte, et écrire un parser qui permette de l'analyser et de récupérer les valeurs. Ecrire un parseur est long, et surtout demande de le retoucher à chaque fois qu'on modifie la syntaxe utilisée dans le fichier. Comme je l'ai expliqué dans un précédent post, pour les fichiers desc et changelog j'ai du écrire un parser à coups de sed, grep et autre cut pour la commande Check. Lorsque Geekitus a proposé d'ajouter une info indiquant la raison de la release d'un paquet, il a fallu que je modifie le parser pour reconnaître cette nouvelle donnée. C'est fastidieux et il y a un risque de casser ce qui fonctionne déjà. De plus, le format des différents fichiers du nbuild n'est pas arrêté, et on va peut-être ajouter de nouvelles infos par la suite, ce qui va encore demander de modifier le parser. En utilisant le format XML, on a un parser prêt à l'emploi et éprouvé. Tous les tests de structure du fichier et de validité des informations sont réalisées directement par le parser XML : il suffit simplement de les indiquer dans un "schéma XML" (c'est un fichier .xsd, une espèce de DTD beaucoup plus puissant, parfaitement géré par le toolkit XmlStarlet. Je suis en train de l'écrire). Ca simplifie donc le code de Ncooker et plus particulièrement de la commande Check car il n'est plus utile de coder ces tests en bash. De simples règles permettent ainsi de vérifier que la valeur "name" des balises <file> est unique dans tout le fichier, par exemple. > deux chose qui vont à contre courant des > objectifs de Nasgaia selon moi. Là encore, c'est le contraire :-) En utilisant le format XML au lieu de bash, on est même plus proche des objectifs définis dans la Charte de Nasgaïa : "Les buts secondaires sont l'utilisation ou le développement d'approches techniques modernes, innovantes, dans le respect le plus strict possible de certaines normes et standards". Un gestionnaire de paquets qui utilise le format XML me semble être une approche qui correspond à ces critères :-) ++ Gontran
