Lorsque dans un programme, tu modifies une variable globale, la valeur de cette variable est changée instantanément pour l'ensemble du programme. Au niveau de la base de registre, c'est exactement ce comportement. Si tu prends les variables d'environnement UNIX, le principe est d'un héritage père fils lors de la création du processus fils. Donc un fils ne peux pas modifier la valeur d'une variable du père ! C'est fondamental. Un fils ne peux pas pertuber un père aussi facilement que via la base de registre. Les processus sont bien plus cloisonnés et globalement le modèle sous jacent est bien plus simple. Des processus, des variables d'environnements héritables, des fichiers. Le pire, c'est que ce modèle simple marche formidablement bien.
Au niveau de ta seconde remarque, je suis en opposition avec cette affirmation. Il y a très peu de paramètres commun entre applications et la base de registre est bourrée de variable propre à chaque application.
Pour le peu de paramètre commun possible, il est bien plus fiable de se mettre d'accord sur un format de fichier commun ou mieux, de définir quelques commandes qui donnent ces fameux paramètres.
Je finirais en disant qu'il est souvent idiot de vouloir transmettre instantanément certaines données d'une application à une autre. Par exemple, lorsque je change le thème de mon bureau, je n'ai pas besoin que les applications changent de thème de suite. Cela peux attendre le prochain lancement de l'application. De même au niveau du gestionaire de fenêtre, les anciens gestionaires de fenêtre avaient une option "Restart" qui permettait de recharger les paramêtres. Cela nécessite une action de l'utilisateur et je trouve ça très bien et bien moins dangereux.
Dernier point, il est tout a fait possible d'envoyer un signal "Reload" à une application pour que celle-ci recharge sa configuration (kill). C'est comme cela que fonctionne la plupart des serveurs (apache par exemple), ca évite de les arrèter et de les relancer. Pourquoi ne pas avoir la même chose avec ses applications de bureau.
Encore une fois, la problèmatique des paramètres partagés entre applications me parait surdimensionnée et mener à une voie dangeureuse.
[^] # Re: On m'a dit aussi de ne pas réinventer la boucle.
Posté par Sytoka Modon (site web personnel) . En réponse à la dépêche Des licences "Shared Source" de Microsoft.... Évalué à 4.
Au niveau de ta seconde remarque, je suis en opposition avec cette affirmation. Il y a très peu de paramètres commun entre applications et la base de registre est bourrée de variable propre à chaque application.
Pour le peu de paramètre commun possible, il est bien plus fiable de se mettre d'accord sur un format de fichier commun ou mieux, de définir quelques commandes qui donnent ces fameux paramètres.
Je finirais en disant qu'il est souvent idiot de vouloir transmettre instantanément certaines données d'une application à une autre. Par exemple, lorsque je change le thème de mon bureau, je n'ai pas besoin que les applications changent de thème de suite. Cela peux attendre le prochain lancement de l'application. De même au niveau du gestionaire de fenêtre, les anciens gestionaires de fenêtre avaient une option "Restart" qui permettait de recharger les paramêtres. Cela nécessite une action de l'utilisateur et je trouve ça très bien et bien moins dangereux.
Dernier point, il est tout a fait possible d'envoyer un signal "Reload" à une application pour que celle-ci recharge sa configuration (kill). C'est comme cela que fonctionne la plupart des serveurs (apache par exemple), ca évite de les arrèter et de les relancer. Pourquoi ne pas avoir la même chose avec ses applications de bureau.
Encore une fois, la problèmatique des paramètres partagés entre applications me parait surdimensionnée et mener à une voie dangeureuse.