Ce système est la tentative de FreeDesktop.org de standardiser un système d'échange d'informations et de données entre applications des environnements de bureau, ou entre applications et le noyau. Chaque application peut ainsi demander ou proposer des services aux autres, ainsi que demander à être informée de l'arrivée ou de la déconnexion à chaud de nouveaux périphériques. Des bus de données munis d'une sémantique sont créés.
Freedesktop.org est une initiative des développeurs de GNOME, KDE, Enlightenment, GStreamer, Xgl/AIGLX ou encore x.org afin de créer des standards communs dans un contexte de développement de code et de spécifications ouvertes.
KDE 4 sera vraisemblablement la première version de KDE à intégrer D-Bus grâce au binding Qtbus de TrollTech. D-Bus succédera donc à DCOP. GNOME est aussi de la partie, puisqu'il est prévu dans la feuille de route de remplacer complètement bonobo par D-Bus. Les principaux concepts de Dbus
- Objet et localisation d'objet : L'objectif consiste à pouvoir retrouver un objet quelconque au moyen d'un chemin unique, comme par exemple /org/kde/kspread/sheets/3/cells/4/5
- Méthodes et signaux : Chaque objet est traditionnellement muni de méthodes, mais dans un environnement hautement dynamique comme un desktop, on peut aussi s'abonner à des signaux, à la manière d'un journal. L'observateur est prévenu lorsqu'un signal qui l'intéresse est émis.
- Interfaces : Description sémantisée d'un objet. Permet aux bindings des différents langages voulant manipuler Dbus de créer des instances d'objets adaptés.
- Proxy : Permet de simplifier les communications, en automatisant la connexion au service et le retour de données.
- Nommage : Chaque application connectée à D-bus se voit attribuer un nom. Chacune d'entre elles peut enregistrer un nom, à la manière des paquetages Java.
- Adresses : À la manière du couple protocole/URL, des adresses peuvent être spécifiées afin d'accéder à diverses ressources. Tous les protocoles sont définis dans la spécification qui est appelée à grossir.
- Messages : Les messages constituent un ensemble de données circulant d'application en application. On y trouve l'envoyeur, le destinataire (à moins qu'il ne s'agisse d'un signal à vocation multipoint), le type d'objet, les méthodes incriminées, etc... C'est le processus D-Bus qui s'occupe de faire passer ceux-ci d'application à application.
Ces quelques définitions sont tirées du Tutoriel D-BUS.
Intégration dans GNOME
Comme évoqué plus haut, GNOME semble bien parti pour adopter complètement D-Bus, Bonobo n'ayant jamais donné autant satisfaction que Dcop. Une ancienne feuille de route donne à ce sujet deux informations intéressantes concernant le début des travaux :
- GNOME 2.8 : Inclusion of DBUS, a system-wide messaging daemon. [Havoc Pennington]
- Échéance non déterminée : Better hardware integration via dbus and a hardware abstraction layer.
La feuille de route actuelle pour GNOME 2.16 / 2.18 confirme une adoption complète de D-Bus, au détriment de bonobo rendu obsolète d'ici GNOME 2.18.
Aller plus loin
- Le projet Dbus sur Freedesktop.org (4 clics)
- Définition de Dbus sur wikipedia (2 clics)
- Le journal de Dup à ce sujet (7 clics)
- Les premiers pas de D-Bus sur la liste de diffusion de Red-Hat (3 clics)
- Certains développeurs de GNOME se posent encore la question du passage à Dbus (1 clic)
- Schéma du fonctionnement général de DBus (4 clics)
# DCop, pas Kpart
Posté par Aurélien Bompard (site web personnel) . Évalué à 10.
D-Bus succédera à DCOP, pas à Kpart, non ?
# Kpart ou Dcop ?
Posté par Infernal Quack (site web personnel) . Évalué à 10.
Il succédera pas plutôt à dcop ? KPart c'est l'intégration d'une application dans une autre et aucunement la communication entre processus.
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: Kpart ou Dcop ?
Posté par Infernal Quack (site web personnel) . Évalué à 3.
Sinon, pareil pour Gnome.D-Bus va remplacer Corba et non Bonobo si j'ai tout compris.
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: Kpart ou Dcop ?
Posté par Philippe F (site web personnel) . Évalué à 10.
Sinon, dbus, c'est de la balle. Cela va permettre de faire des services qui pourront être utilisés par tous les environnements de bureau de façon indifférente.
Les notifications hardware sont les premiers services à être intégrés dans dbus, mais il va y en avoir d'autres. C'est grâce à des projets comme ça que les bureaux libres peuvent avancer sans se marcher sur les pieds les uns les autres.
Le blog de Aaron Seigo parle d'un dbus-viewer, successeur du kdcop :
http://aseigo.blogspot.com/2006/11/dbus-viewer.html
Dans les autres projets freedesktop qui assurent, citons le package xdg-utils maintenant développé au sein du groupe de portland.
http://portland.freedesktop.org/xdg-utils-1.0/
xdg-utils permet de faire des opérations standards pour plusieurs desktop :
- installer une entrée menu pour une application
- lancer l'application associée à un fichier donné
- contrôle le screen saver
C'est rien mais le niveau d'intégration qu'il faut pour faire ces choses proprement sur chaque desktop est loin d'être ridicule.
Globalement, ca fait plaisir de voir des leaders des différents projets avancer ensemble sur ces sujets.
[^] # Re: Kpart ou Dcop ?
Posté par Infernal Quack (site web personnel) . Évalué à 2.
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: Kpart ou Dcop ?
Posté par yoplait . Évalué à 5.
Y a régulièrement des types qui veulent lancer la discussion mais je crois que c'est encore un sujet tabou : http://live.gnome.org/ThreePointZero/Bonobo
[^] # Re: Kpart ou Dcop ?
Posté par liberforce (site web personnel) . Évalué à 3.
[^] # Re: Kpart ou Dcop ?
Posté par Vivi (site web personnel) . Évalué à 1.
Orbit et bonobo resteront de toutes façons dans la plate-forme pour assurer la compatibilité binaire. Relativement peu de programmes utilisent ça, ça marche pas trop mal, y'a pas de raison d'y toucher.
Maintenant si le mainteneur d'un projet utilisant bonobo veut remplacer bonobo par D-Bus, libre à libre lui de le faire (sauf si on considère que cette interface bonobo fasse partie de l'API publique de l'application, auquel c'est figé).
[^] # Re: Kpart ou Dcop ?
Posté par Philippe F (site web personnel) . Évalué à 10.
http://telepathy.freedesktop.org/wiki/
Les développeurs de kopete sont en train d'étudier une migration complète vers telepathy, et on commencer quelques tests avec un plugin. Je pense que ça voudrait dire plein de bonnes choses pour les deux projets.
[^] # Re: Kpart ou Dcop ?
Posté par Mathieu Pillard (site web personnel) . Évalué à 5.
[^] # Re: Kpart ou Dcop ?
Posté par Christophe Merlet (site web personnel) . Évalué à 5.
nautilus, gnome-vfs, epiphany, gnome-power-manager l'utilise, mais aussi gaim, rhythmbox, ...
# KPart ?
Posté par Oscar Blumberg . Évalué à 10.
Heuuu, DCOP plutot non ?
[^] # Given enough eye balls...
Posté par Amine "nh2" Brikci-Nigassa (site web personnel) . Évalué à 8.
GNU's Not Unix / LINUX Is Not Unix Xernel
# perdu ! j'parlerai pas de D-Bus/KPart/Dcop
Posté par Rémi Hérilier . Évalué à 3.
Méthodes et signaux : Chaque méthode est traditionnellement munie de méthodes, mais dans un...
c'est pas plutôt « chaque objet est traditionnellement muni... » ?
[^] # Re: perdu ! j'parlerai pas de D-Bus/KPart/Dcop
Posté par Infernal Quack (site web personnel) . Évalué à 10.
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: perdu ! j'parlerai pas de D-Bus/KPart/Dcop
Posté par Xavier Teyssier (site web personnel) . Évalué à 3.
[^] # Re: perdu ! j'parlerai pas de D-Bus/KPart/Dcop
Posté par Pierre Jarillon (site web personnel) . Évalué à 4.
Pour avoir rédigé quelques articles, je dois dire que c'est beaucoup plus long à faire qu'on ne le croit de prime abord.
[^] # Re: perdu ! j'parlerai pas de D-Bus/KPart/Dcop
Posté par Sytoka Modon (site web personnel) . Évalué à 8.
D'un autre coté, je ne la trouve pas si mal cette dépêche.
Un point important à mon sens avec D-BUS est que normalement, cela ne tourne pas en root. Chacun a le sien. Je ne sais pas par contre comment les D-BUS communiquent entre eux ? (Le D-BUS utilisateur est-il client du D-BUS système) Cela est un plus par exemple avec le service 'fam' de notification de mofication de fichier qui devait absolument tourner en root, avec les problèmes que l'on connait pour les périphériques amovibles (il faut voir les astuces qui ont été réalisés sur ce point là à une époque pas si lointaines).
Un autre point important est que D-BUS est un bus de messages et de signaux. Cela n'a donc rien à voir avec un système de variable globale de type base de registre ou gconf. Cela me fait plus penser au système de message à la base d'OpenStep. Or tout le monde sait qu'OpenStep (donc GnuStep) qui fonctionne par message avec un langage objet dynamique (ObjectiveC) a montré depuis des années une souplesse de fonctionnement et d'adaptation aux problèmes avec une API d'une incroyable stabilité.
[^] # Re: perdu ! j'parlerai pas de D-Bus/KPart/Dcop
Posté par ookaze . Évalué à 8.
Les dbus utilisaeurs ne tournent pas en root, mais le dbus système tourne en root au moins au lancement, pour lacher ses droits ensuite.
Le dbus système, je ne sais pas s'il est serveur, mais il communique avec tous les autres, comme un fédérateur. S'il tombe, tous les autres tombent avec (enfin, deviennent inutilisables).
Cela est un plus par exemple avec le service 'fam' de notification de mofication de fichier qui devait absolument tourner en root, avec les problèmes que l'on connait pour les périphériques amovibles
fam est toujours nécessaire. Gamin est plus adapté à la plupart des gens, et n'a pas besoin de tourner en service.
Un autre point important est que D-BUS est un bus de messages et de signaux. Cela n'a donc rien à voir avec un système de variable globale de type base de registre ou gconf
Etant donné que GConf utilise également des messages et des signaux (surtout), je me pose des questions quant au "ça n'a rien à voir".
[^] # Re: perdu ! j'parlerai pas de D-Bus/KPart/Dcop
Posté par Elrik de Melnibone . Évalué à 2.
[^] # Re: perdu ! j'parlerai pas de D-Bus/KPart/Dcop
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Au niveau fam et gamin, en pratique, cela est remplacé par inotify directement par le noyau. Par contre, on doit pouvoir utiliser D-BUS pour la transmission finale ?
Quand à la fin, que gconf utilise dans le futur D-BUS pour transmette ses informations, pourquoi pas. Mais cela n'a effectivement rien à voir. Un des objectifs de gconf est quand même de centraliser les paramètres de configurations des applications. Après, gconf fait plus que cela mais justement, je fait partie des personnes qui trouve qu'il en fait bien trop ;-) Si D-BUS lui enlève une partie du boulot, tant mieux.
[^] # Re: perdu ! j'parlerai pas de D-Bus/KPart/Dcop
Posté par Vivi (site web personnel) . Évalué à 2.
Euh non, je suis pratiquement sûr que non. Qu'est-ce qui te fait penser ça ?
[^] # Re: perdu ! j'parlerai pas de D-Bus/KPart/Dcop
Posté par ookaze . Évalué à 2.
Et j'ai fait les tests une fois avec les outils en ligne de commande fournis, et effectivement, je n'arrivais plus à obtenir quoi que ce soit.
Ca m'est arrivé aussi bien sous Gnome que sous KDE.
K3B s'en sortait bien, il restait juste bloqué pendant plusieurs minutes.
Rhythmbox en revanche ...
Ceci dit, K3B recherchait des infos HAL, alors que Rhythmbox voulait communiquer avec libnotify (enfin, je pense).
Une relance de chaque session (qui relance aussi les daemons DBus utilisateurs), règle le souci.
[^] # Re: perdu ! j'parlerai pas de D-Bus/KPart/Dcop
Posté par Damien (site web personnel) . Évalué à 2.
# .
Posté par lambada . Évalué à -1.
s/méthode/objet/ ?
[^] # Re: .
Posté par Nicolas Dumoulin (site web personnel) . Évalué à -1.
"Chaque objet est traditionnellement munie de objets" ?
non, ça ne colle pas ;-)
[^] # Re: .
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 2.
"Chaque objet est traditionnellement munie de objets" ?
Ding ! Merci d'avoir joué !
(Il a dit "s/méthode/objet/" et non "s/méthode/objet/g")
[^] # Re: .
Posté par Nicolas Dumoulin (site web personnel) . Évalué à 1.
N'empêche que ça ne règle pas le problème du « munie » qui est mal accordé :o
[^] # Re: .
Posté par theocrite (site web personnel) . Évalué à 2.
"Chaque objet est traditionnellement munie de méthodes"
Parce qu'il n'a pas mis de 'g' à la fin ;)
# la belle vie
Posté par Jeanuel (site web personnel) . Évalué à 10.
C'est quand même pas une paille d'arriver à faire bosser des mecs aux 4 coins du monde, sur leur temps libre, pendant plusieurs années sur de vagues projets qui aboutirons à des résultats invisibles pour le plus grand nombre.
Merci à eux. Leur travail est à la base de tout le reste.
[^] # Re: la belle vie
Posté par Axel R. (site web personnel) . Évalué à 6.
Finalement, y'a ceux qui parlent et ceux qui font...
Bon, bah moi j'vais me taire.
Axel
[^] # Re: la belle vie
Posté par Christophe Fergeau . Évalué à 10.
Les développeurs principaux de DBus (Havoc Pennington, puis John Palmieri, et David Zeuthen qui travaillait sur des trucs "autour" de DBus) sont tous payés par RedHat pour bosser dessus... ;)
[^] # Re: la belle vie
Posté par Pierre Jarillon (site web personnel) . Évalué à 1.
C'est le besoin de ce genre de rencontre qui m'a donné l'idée des RMLL fin 1999.
[^] # Re: la belle vie
Posté par Jean Roc Morreale . Évalué à 10.
Mr Jarillon, c'est tout à votre honneur d'avoir créé les RMLL mais là ça doit être la 25ème itération cuvée 2006 de cette phrase répétée ad nauseam "C'est le besoin de ce genre de rencontre qui m'a donné l'idée des RMLL fin 1999" (ça c'est la 26ème, cadeau bonux). Il faudrait varier, merci. :)
[^] # Re: la belle vie
Posté par Antoine . Évalué à 5.
[^] # Re: la belle vie
Posté par _Hitek_ (site web personnel) . Évalué à 2.
http://www.google.fr/custom?hl=fr&client=pub-73605532899(...)
[^] # Re: la belle vie
Posté par liberforce (site web personnel) . Évalué à 2.
Voilà, c'était la minute "Gala/Voici/Entrevue".
# D-Bus et Upstart
Posté par Nicolas Legrand (site web personnel) . Évalué à 1.
https://wiki.ubuntu.com/ReplacementInit
[^] # Re: D-Bus et Upstart
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
[^] # Re: D-Bus et Upstart
Posté par LeMagicien Garcimore . Évalué à 4.
[^] # Re: D-Bus et Upstart
Posté par Elrik de Melnibone . Évalué à 6.
Une bonne grosse choucroute garnie :-)
Upstart sera informé de se qu'il se passe au niveau hardware grâce à HAL (connexions à chaud, état du réseau, tout ca).
Or HAL communique avec les autres applications grâce à D-BUS.
Conclusion Upstart utilisera D-Bus.
Voilà, pas de quoi s'énerver ;-)
# Un beau produit a base de dbus
Posté par Pierre . Évalué à 3.
Ca permet facilement de developper la GUI sur son desktop, en simulant l'emission de signaux. Moins evident, si les applis de GUI vont recuperer leurs infos dans /sys ou dans un /dev..
# CooL
Posté par Romain Liévin (site web personnel) . Évalué à -1.
[^] # Re: CooL
Posté par Ph Husson (site web personnel) . Évalué à 0.
C'est pas que mais l'utilisateur il en a quoi à faire du système de transmission de messages entre applis ?
Vu que c'est justement les applis qui doivent s' en occuper, et pas l'utilisateur !
À moins que quelque chose ne m'ai échappé.
# Et la concurrence ??
Posté par GuieA_7 (site web personnel) . Évalué à 3.
Merci d'avance.
[^] # Re: Et la concurrence ??
Posté par Bonnefille Guilhem (site web personnel) . Évalué à 7.
# D-Bus, Bonobo & co.
Posté par HappyPeng . Évalué à 10.
En effet, Bonobo est un système de composants complet, relativement complexe et qui se voulait comparable dans son architecture à COM, et qui a le malheur d'être construit au-dessus (et non à côté comme on pourrait le dire par exemple de la relation entre KParts et DCOP) d'un système d'IPC déjà relativement évolué, CORBA.
D-Bus par contre n'est résolument qu'un système d'IPC (et il a été voulu en tant que tel), qui fournit encore moins de services que CORBA. Il ne peut par construction pas rendre les mêmes services qu'un système de composants comme COM, ou même en fait comme KParts.
Le problème des systèmes de composants pour les applications orientées "desktop" reste donc non résolu, et il est clair pour moi qu'il se pose bien à part de la communication entre applications.
Précision d'une part de mes pensées : http://blogs.hurdfr.org/happypeng/?title=midtalk_ii_plugins&(...)
Mon début de contribution à une solution :
http://midtalk.happypeng.org/
N'hésitez pas à me contacter si le sujet vous intéresse.
[^] # Re: D-Bus, Bonobo & co. XPCOM ?
Posté par free2.org . Évalué à 2.
http://www.mozilla.org/projects/xpcom/
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.