Oh !
Bon, ayant deja utilise des formats binaires et l'ayant regrette, je me dois de reagir.
Je n'ai pas dit que le stockage binaire était la solution parfaite ou universelle. Simplement si une "couche d'abstraction" était proposée pour distinguer "l'inferface utilisateur" et "l'interface programme" pour la config, chacun pourrait choisir s'il préfère maintenir des fichiers textes (convertis / "compilés" ensuite vers la base de registres qui ne serait qu'un cache) ou un éditeur distinct qui utiliserait directement la lib (dans mon exemple berkeley DB) pour écrire dedans.
Il me semble que KDE utilise déjà un schéma similaire (même si le format binaire n'est qu'un cache sur des fichiers txt), et que e17 adopte aussi la même approche (avec edb)...
En tout cas en ce qui me concerne j'aurais vite fait mon choix, car j'estime que le problème du stockage / récupération de paires "clé = valeur" est résolu depuis longtemps, de manière efficace par les SGBD, et que par conséquent ce n'est pas au programmeur de refaire ce boulot en moins bien.
Ca oblige a parser du binaire. A tenir compte du big/little endian
?!?
Mais non, on ne parse rien ! Pour le programmeur tout doit être transparent (avec une lib dédiée).
Tout ce que le programmeur voit, c'est qu'il peut insérer / lire (rapidement puisque c'est indexé) des paires clé = valeur, sans rien avoir à parcourir puisque c'est la DB qui le fait pour lui... Par contre avec des fichiers txt c'est le programme lui-même qui doit faire tout le boulot (=> code bloat, sauf peut-être s'il utilise un truc comme gconf (que je ne connais pas donc je ne jugerai pas)). La chaîne "ma_cle = 120" prend 12 octets sans signification pour la machine alors qu'un stockage binaire {clé = "ma_clé", valeur = 120} est moins gourmand et surtout beaucoup plus vite retrouvé et "compris"...
Par exemple, un nom d'utilisateur, c'est du texte, pas du binaire
Bien sûr, mais tu fais une distinction superflue entre texte et binaire. Un fichier "binaire" (i.e. non 100 % ASCII) peut très bien contenir des chaînes de caractères ASCII (pour les clés comme pour les valeurs) et sans conversion aucune. Pour l'endianness, on stocke les données comme on veut (et dans tous les cas au pire ça prend moins de cycles de convertir l'endianness que de convertir un nombre de l'ASCII vers le binaire !)
il faut un editeur specifique pour une base BerkeleyDB
Rien n'empêche d'imaginer des convertisseurs ASCII<->DB pour les durs de durs qui veulent absolument utiliser vi ! Par contre on n'est plus _obligé_ de se taper la conf au format texte
Outils de dump/recovery. Ils existent aussi pour les fichiers texte. Mon prefere s'appelle "cp"...
OK. Mais normalement le problème de l'intégrité dans les bases de données est résolu depuis longtemps aussi (regardes combien de données critiques sont stockées (en binaires) par les SGBD). Si la base supporte les transactions normalement ça ne devrait pas poser problème ! D'autre part pour l'utilisateur lambda un fichier texte "corrompu" sera au moins aussi difficile à restaurer, à moins qu'il n'ait le courage de se replonger dans la doc...
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 !
Nan, bien sûr, mais j'ai surtout voulu insister non pas sur le CPU mais sur le code bloat vu qu'actuellement une quantité non négligeables de code est écrit juste pour parser la conf. Effectivement je ne sais pas trop comment ça se passe avec gconf ou libconf, et si l'un de ces systèmes était adopté de manière universelle le pb serait résolu puisqu'il suffirait que le "backend" soit suffisamment modulaire pour qu'on puisse au choix utiliser du txt ou du binaire...
Je prefere glibc qui implement des fonctions de lecture de fichiers texte (fgets, fputs) comme couche d'abstraction, mais c'est mon avis :)
Je préfère une espèce de "libconf universelle" qui serait utilisée par tous et serait suffisamment modulaire pour ne pas contraindre le programmeur et l'utilisateur à un schéma particulier ! fgets/fputs ce n'est pas une couche d'abstraction puisque l'appli dicte encore _comment_ enregistrer ses données (ce qu'on voulait justement abstraire).
[^] # Re: Moi je trouve que c'est une bonne idée
Posté par karteum59 (site web personnel) . En réponse à la dépêche Une base de registre pour Linux ?. Évalué à 1.
Bon, ayant deja utilise des formats binaires et l'ayant regrette, je me dois de reagir.
Je n'ai pas dit que le stockage binaire était la solution parfaite ou universelle. Simplement si une "couche d'abstraction" était proposée pour distinguer "l'inferface utilisateur" et "l'interface programme" pour la config, chacun pourrait choisir s'il préfère maintenir des fichiers textes (convertis / "compilés" ensuite vers la base de registres qui ne serait qu'un cache) ou un éditeur distinct qui utiliserait directement la lib (dans mon exemple berkeley DB) pour écrire dedans.
Il me semble que KDE utilise déjà un schéma similaire (même si le format binaire n'est qu'un cache sur des fichiers txt), et que e17 adopte aussi la même approche (avec edb)...
En tout cas en ce qui me concerne j'aurais vite fait mon choix, car j'estime que le problème du stockage / récupération de paires "clé = valeur" est résolu depuis longtemps, de manière efficace par les SGBD, et que par conséquent ce n'est pas au programmeur de refaire ce boulot en moins bien.
Ca oblige a parser du binaire. A tenir compte du big/little endian
?!?
Mais non, on ne parse rien ! Pour le programmeur tout doit être transparent (avec une lib dédiée).
Tout ce que le programmeur voit, c'est qu'il peut insérer / lire (rapidement puisque c'est indexé) des paires clé = valeur, sans rien avoir à parcourir puisque c'est la DB qui le fait pour lui... Par contre avec des fichiers txt c'est le programme lui-même qui doit faire tout le boulot (=> code bloat, sauf peut-être s'il utilise un truc comme gconf (que je ne connais pas donc je ne jugerai pas)). La chaîne "ma_cle = 120" prend 12 octets sans signification pour la machine alors qu'un stockage binaire {clé = "ma_clé", valeur = 120} est moins gourmand et surtout beaucoup plus vite retrouvé et "compris"...
Par exemple, un nom d'utilisateur, c'est du texte, pas du binaire
Bien sûr, mais tu fais une distinction superflue entre texte et binaire. Un fichier "binaire" (i.e. non 100 % ASCII) peut très bien contenir des chaînes de caractères ASCII (pour les clés comme pour les valeurs) et sans conversion aucune. Pour l'endianness, on stocke les données comme on veut (et dans tous les cas au pire ça prend moins de cycles de convertir l'endianness que de convertir un nombre de l'ASCII vers le binaire !)
il faut un editeur specifique pour une base BerkeleyDB
Rien n'empêche d'imaginer des convertisseurs ASCII<->DB pour les durs de durs qui veulent absolument utiliser vi ! Par contre on n'est plus _obligé_ de se taper la conf au format texte
Outils de dump/recovery. Ils existent aussi pour les fichiers texte. Mon prefere s'appelle "cp"...
OK. Mais normalement le problème de l'intégrité dans les bases de données est résolu depuis longtemps aussi (regardes combien de données critiques sont stockées (en binaires) par les SGBD). Si la base supporte les transactions normalement ça ne devrait pas poser problème ! D'autre part pour l'utilisateur lambda un fichier texte "corrompu" sera au moins aussi difficile à restaurer, à moins qu'il n'ait le courage de se replonger dans la doc...
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 !
Nan, bien sûr, mais j'ai surtout voulu insister non pas sur le CPU mais sur le code bloat vu qu'actuellement une quantité non négligeables de code est écrit juste pour parser la conf. Effectivement je ne sais pas trop comment ça se passe avec gconf ou libconf, et si l'un de ces systèmes était adopté de manière universelle le pb serait résolu puisqu'il suffirait que le "backend" soit suffisamment modulaire pour qu'on puisse au choix utiliser du txt ou du binaire...
Je prefere glibc qui implement des fonctions de lecture de fichiers texte (fgets, fputs) comme couche d'abstraction, mais c'est mon avis :)
Je préfère une espèce de "libconf universelle" qui serait utilisée par tous et serait suffisamment modulaire pour ne pas contraindre le programmeur et l'utilisateur à un schéma particulier ! fgets/fputs ce n'est pas une couche d'abstraction puisque l'appli dicte encore _comment_ enregistrer ses données (ce qu'on voulait justement abstraire).