A propose de gconf, il y a des paramètres dans gconf qui sont pris en charge instantanément. Ce n'est pas le cas des fichiers de configuration. Si tu modifie la configuration d'Apache par exemple, il faut lui envoyer le signal HUP pour qu'il recharge a chaud sa configuration. C'est le "restart" des anciens Window Manager basé sur le génial fvwm.
Dans un environnement gnome moderne, tu change un paramètre a un endroit et ca change partout instantanément. C'est beau mais je pense que c'est une mauvaise idée.
Le concept des UNIX est très simple. Des processus ayant des variables d'environnement qu'ils transmettre a leur fils, JAMAIS l'inverse ! Un fils a très peu de pouvoir sur un père (et réciproquement). Il faut mettre en place des outils de plus haut niveau pour faire communiquer les processus (segment de mémoire partagé...)
Pour en revenir a gconf, s'il ne remplacais que les fichiers de configuration, pourquoi tourne-t-il en mode daemon. Ce serait une simple librairie dynamique que le programme chargerait au démarrage, que ce serait très bien.
Le problème est que gconf sers aussi a partager des données entre le programmes et ce n'est pas son rôle, en tout cas, je ne suis pas de cet avis. En plus, le nombre de paramètre a partager est très faible devant la quantité de paramètre spécifique à chaque programme. Bref, que ce rôle revienne à une autre application, pourquoi pas au D-BUS...
[^] # Re: Comme promis ...
Posté par Sytoka Modon (site web personnel) . En réponse au journal Fluxbox 0.9.15. Évalué à 2.
Dans un environnement gnome moderne, tu change un paramètre a un endroit et ca change partout instantanément. C'est beau mais je pense que c'est une mauvaise idée.
Le concept des UNIX est très simple. Des processus ayant des variables d'environnement qu'ils transmettre a leur fils, JAMAIS l'inverse ! Un fils a très peu de pouvoir sur un père (et réciproquement). Il faut mettre en place des outils de plus haut niveau pour faire communiquer les processus (segment de mémoire partagé...)
Pour en revenir a gconf, s'il ne remplacais que les fichiers de configuration, pourquoi tourne-t-il en mode daemon. Ce serait une simple librairie dynamique que le programme chargerait au démarrage, que ce serait très bien.
Le problème est que gconf sers aussi a partager des données entre le programmes et ce n'est pas son rôle, en tout cas, je ne suis pas de cet avis. En plus, le nombre de paramètre a partager est très faible devant la quantité de paramètre spécifique à chaque programme. Bref, que ce rôle revienne à une autre application, pourquoi pas au D-BUS...