Oh !
Bon, ayant deja utilise des formats binaires et l'ayant regrette, je me dois de reagir.
un parser pour chaque type de fichier de config
Libconf: http://www.libconf.net/(...)
Ceci dit, ce genre de projets est tres bien, mais est un gros hack pour une mauvaise conception a la base. La registry permet d'ameliorer la conception du systeme de config et rend theoriquement libconf inutile.
un format binaire "natif" (ça évite de parser du texte à chaque fois et ça économise donc du CPU)
Ca oblige a parser du binaire. A tenir compte du big/little endian.
En cas de deterioration des outils de lecture (comme BerkeleyDB dont tu parles plus loin) suite a un bug, c'est beaucoup plus complique a remettre en place que du texte.
Si l'on veut passer un fichier d'une machine a l'autre pour eviter de recopier une config qui marche, en modifiant une ou deux petites choses, on est oblige d'utiliser l'editeur de conf. L'editeur vi (ou emacs) ne suffit pas.
Concernant le CPU, tu economises quelques dizaines de millisecondes a chaque lancement du programme. Ca doit te faire gagner grand maximum une 10aine de secondes dans une journee. Wow ! Ce n'est pas comme si on avait une boucle qui itere des milliers de fois sur ce genre de choses !
Concernant le CPU encore, il ne faut pas oublier la conversion binaire->texte qui coute du CPU, alors que lire du texte en natif, ca aide ! Par exemple, un nom d'utilisateur, c'est du texte, pas du binaire. Un nom de fichier, c'est du texte aussi. Et pour les nombres, entre une conversion little/big endian et une conversion texte->binaire, gagne-t-on tant que ca ? Que faire si le format du nombre passe de 16 bits a 32 bits parce que cela a mal ete pense au debut ? Ca me rappelle les ordis de 640 ko et Bill Gates qui a dit (en 1981) que ca devrait suffire a tout le monde! (*)
avec un truc "standard" comme par ex BerkeleyDB, qui disposent tout de même de fonctionnalités de dump/recovery
Compatif de "standards" :)
berkeleyDB vs fichier texte : il faut un editeur specifique pour une base BerkeleyDB, contre n'importe quel editeur de texte pour un fichier texte.
Outils de dump/recovery. Ils existent aussi pour les fichiers texte. Mon prefere s'appelle "cp" meme s'il m'arrive parfois d'utiliser "mv" :)
L'important est de séparer la récupération de la config par les applis de la saisie des infos de config
Ca, c'est le plus important !
BerkeleyDB me semble être un bon choix pour une "couche d'abstraction"
Je prefere glibc qui implement des fonctions de lecture de fichiers texte (fgets, fputs) comme couche d'abstraction, mais c'est mon avis :)
Le bonjour chez vous,
Yves
(*) y'en a un autre qui a dit que GNU/Linux ne tournerait jamais sur autre chose que sur un PC 80386. S'appelait Linus Torvalds, le bougre :)
[^] # Re: Moi je trouve que c'est une bonne idée
Posté par a_jr . En réponse à la dépêche Une base de registre pour Linux ?. Évalué à 6.
Bon, ayant deja utilise des formats binaires et l'ayant regrette, je me dois de reagir.
un parser pour chaque type de fichier de config
Libconf: http://www.libconf.net/(...)
Ceci dit, ce genre de projets est tres bien, mais est un gros hack pour une mauvaise conception a la base. La registry permet d'ameliorer la conception du systeme de config et rend theoriquement libconf inutile.
un format binaire "natif" (ça évite de parser du texte à chaque fois et ça économise donc du CPU)
Ca oblige a parser du binaire. A tenir compte du big/little endian.
En cas de deterioration des outils de lecture (comme BerkeleyDB dont tu parles plus loin) suite a un bug, c'est beaucoup plus complique a remettre en place que du texte.
Si l'on veut passer un fichier d'une machine a l'autre pour eviter de recopier une config qui marche, en modifiant une ou deux petites choses, on est oblige d'utiliser l'editeur de conf. L'editeur vi (ou emacs) ne suffit pas.
Concernant le CPU, tu economises quelques dizaines de millisecondes a chaque lancement du programme. Ca doit te faire gagner grand maximum une 10aine de secondes dans une journee. Wow ! Ce n'est pas comme si on avait une boucle qui itere des milliers de fois sur ce genre de choses !
Concernant le CPU encore, il ne faut pas oublier la conversion binaire->texte qui coute du CPU, alors que lire du texte en natif, ca aide ! Par exemple, un nom d'utilisateur, c'est du texte, pas du binaire. Un nom de fichier, c'est du texte aussi. Et pour les nombres, entre une conversion little/big endian et une conversion texte->binaire, gagne-t-on tant que ca ? Que faire si le format du nombre passe de 16 bits a 32 bits parce que cela a mal ete pense au debut ? Ca me rappelle les ordis de 640 ko et Bill Gates qui a dit (en 1981) que ca devrait suffire a tout le monde! (*)
avec un truc "standard" comme par ex BerkeleyDB, qui disposent tout de même de fonctionnalités de dump/recovery
Compatif de "standards" :)
berkeleyDB vs fichier texte : il faut un editeur specifique pour une base BerkeleyDB, contre n'importe quel editeur de texte pour un fichier texte.
Outils de dump/recovery. Ils existent aussi pour les fichiers texte. Mon prefere s'appelle "cp" meme s'il m'arrive parfois d'utiliser "mv" :)
L'important est de séparer la récupération de la config par les applis de la saisie des infos de config
Ca, c'est le plus important !
BerkeleyDB me semble être un bon choix pour une "couche d'abstraction"
Je prefere glibc qui implement des fonctions de lecture de fichiers texte (fgets, fputs) comme couche d'abstraction, mais c'est mon avis :)
Le bonjour chez vous,
Yves
(*) y'en a un autre qui a dit que GNU/Linux ne tournerait jamais sur autre chose que sur un PC 80386. S'appelait Linus Torvalds, le bougre :)