D-Bus 1.0, future fondation de nos bureaux

Posté par  (site web personnel) . Modéré par Jaimé Ragnagna.
Étiquettes :
0
14
nov.
2006
Technologie
FreeDesktop.org a annoncé le 9 novembre la sortie de D-Bus 1.0 après quelques années de travail.

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

  • # DCop, pas Kpart

    Posté par  (site web personnel) . Évalué à 10.

    > D-Bus succédera donc à Kpart

    D-Bus succédera à DCOP, pas à Kpart, non ?

  • # Kpart ou Dcop ?

    Posté par  (site web personnel) . Évalué à 10.

    "D-Bus succédera donc à Kpart"

    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  (site web personnel) . Évalué à 3.

      Oh le beau powa !

      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  (site web personnel) . Évalué à 10.

        Bonobo, c'est la surcouche de Corba qui permet aux applis Gnome de communiquer. Je pense que la phrase est juste, dbus va remplacer bonobo et par là même Corba.

        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  (site web personnel) . Évalué à 2.

          Merci pour ta réponse. 1000 fois plus constructive que le mec qui m'a moinssé pour me dire que j'avais tort.

          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  . Évalué à 5.

            Pour moi t'avais raison. Bonobo c'était l'équivalent de kpart, construit sur une couche de CORBA. Tout le monde veut s'enfuir de cette couche pour adopter D-Bus, mais pour tout ce qui est intégration de composants, personne n'en parle vraiment. Faut dire que malheureusement c'est pas une techno fort utilisée dans GNOME.

            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  (site web personnel) . Évalué à 3.

              Une précision: l'implémentation de CORBA utilisé dans GNOME est Orbit.

            • [^] # Re: Kpart ou Dcop ?

              Posté par  (site web personnel) . Évalué à 1.

              C'est pas tabou, c'est juste qu'il n'y a pas lieu à discussion.

              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  (site web personnel) . Évalué à 10.

          Je rajoute aussi un lien vers telepathy :

          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  (site web personnel) . Évalué à 5.

          Au passage, il y avait un dbus-viewer en gtk, qui était un peu plus limité que celui que tu cites, il semble avoir disparu. Quelqu'un a plus d'infos sur ce que c'est devenu?

      • [^] # Re: Kpart ou Dcop ?

        Posté par  (site web personnel) . Évalué à 5.

        GNOME intègre DBus depuis un bon moment.

        nautilus, gnome-vfs, epiphany, gnome-power-manager l'utilise, mais aussi gaim, rhythmbox, ...

  • # KPart ?

    Posté par  . Évalué à 10.

    DBus succedera a KPart ?
    Heuuu, DCOP plutot non ?

  • # perdu ! j'parlerai pas de D-Bus/KPart/Dcop

    Posté par  . Évalué à 3.

    mais de

    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  (site web personnel) . Évalué à 10.

      Et après on nous bassine que si les news mettent du temps à être publiée c'est parce qu'il y a des relecteurs /o\

      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  (site web personnel) . Évalué à 3.

        En même temps, cette news, j'ai pas l'impression qu'elle est passée plus de 4 heures dans la file de modération...

        • [^] # Re: perdu ! j'parlerai pas de D-Bus/KPart/Dcop

          Posté par  (site web personnel) . Évalué à 4.

          C'est vrai, elle n'a pas été assez relue par les modérateurs mais elle n'a pas été également assez relue par son auteur...
          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  (site web personnel) . Évalué à 8.

            Je n'en ai pas fait beaucoup mais c'est vrai que cela m'a pris en général ma soirée.

            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  . Évalué à 8.

              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)

              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  . Évalué à 2.

                Il y a des discutions sur l'écriture d'un backend gconf utilisant DBus.

              • [^] # Re: perdu ! j'parlerai pas de D-Bus/KPart/Dcop

                Posté par  (site web personnel) . Évalué à 2.

                Si le D-BUS principal tombe et que tous les autres tombent alors, cela perds pas mal de son intérêt ! Cela veut dire que l'on ne peut pas relancer le D-BUS sytème sans perturber les autres violament.

                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  (site web personnel) . Évalué à 2.

                il communique avec tous les autres, comme un fédérateur. S'il tombe, tous les autres tombent avec (enfin, deviennent inutilisables).

                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  . Évalué à 2.

                  C'est que à chaque fois que je mets à jour mon DBus, je relance le daemon système pour qu'il prenne la nouvelle version en cours, et par la suite, toutes mes applis utilisant DBus refusent de se lancer et préfèrent planter. Les dbus utilisateurs continuent de tourner, mais ils sont en fait inutilisables (et ça l'a toujours fait, même avec des versions mineures de DBus).
                  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  (site web personnel) . Évalué à 2.

      j'allais le dire, mais en smalltalk les méthodes sont des objets, donc ptet que... :)

  • # .

    Posté par  . Évalué à -1.

    "Chaque méthode est traditionnellement munie de méthodes" ?

    s/méthode/objet/ ?

    • [^] # Re: .

      Posté par  (site web personnel) . Évalué à -1.

      Ce qui donnerait :
      "Chaque objet est traditionnellement munie de objets" ?

      non, ça ne colle pas ;-)

      • [^] # Re: .

        Posté par  (site web personnel) . Évalué à 2.

        Ce qui donnerait :
        "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  (site web personnel) . Évalué à 2.

        Non ça fait
        "Chaque objet est traditionnellement munie de méthodes"

        Parce qu'il n'a pas mis de 'g' à la fin ;)

  • # la belle vie

    Posté par  (site web personnel) . Évalué à 10.

    Quand je vois des trucs pareils, je suis impressioné.

    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  (site web personnel) . Évalué à 6.

      surtout quand on sait que les types en question travaillent sur des projets qui ont généré des milliers de trolls velus...

      Finalement, y'a ceux qui parlent et ceux qui font...

      Bon, bah moi j'vais me taire.

      Axel

    • [^] # Re: la belle vie

      Posté par  . Évalué à 10.

      « C'est quand même pas une paille d'arriver à faire bosser des mecs sur leur temps libre »

      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  (site web personnel) . Évalué à 1.

        Ce serait bien d'inviter le développeurs de D-Bus, de FreeDesktop, de Gnome et de KDE de venir se rencontrer aux RMLL à Amiens en 2007.
        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  . Évalué à 10.

          Bon je suis bien consciens de l'inutilité de ce post, n'ayez aucun remord.

          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  (site web personnel) . Évalué à 2.

        Au passage, John Palmieri s'est retrouvé dans Jokosher, le logiciel de mixage audio, lors de sa prestation scénique au GUADEC 2006: http://www.j5live.com/?p=222

        Voilà, c'était la minute "Gala/Voici/Entrevue".

  • # D-Bus et Upstart

    Posté par  (site web personnel) . Évalué à 1.

    La question que je me pause surtout vis à vis de D-Bus (qui est une petit merveille) c'est l'interaction qu'il aura à terme avec le upstart d'Ubuntu, puisque le upstart en question semble vouloir faire plein de choses que D-Bus fait à la place de D-Bus en ne l'utilisant plus que pour passer les messages :

    https://wiki.ubuntu.com/ReplacementInit

    • [^] # Re: D-Bus et Upstart

      Posté par  (site web personnel) . Évalué à 2.

      A mon avis, upstart s'adpatera à D-BUS ou mourra ;-)

    • [^] # Re: D-Bus et Upstart

      Posté par  . Évalué à 4.

      Heuuu je suis peut être en train de passer a côté d'un truc enorme, mais c'est quoi le rapport avec la choucroute ?

      • [^] # Re: D-Bus et Upstart

        Posté par  . Évalué à 6.

        T'inquiète, t'es pas le seul !
        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  . Évalué à 3.

    Rappelons que le systeme du nokia 770, maemo, est fortement base sur dbus. C'est peut etre meme le systeme qui exploite le plus ces possibilitees, notement au niveau de la communication entre le noyau et les application, certaines interruptions attrapees dans le noyau remontent tout simplement a la GUI via un joli signal dbus..

    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  (site web personnel) . Évalué à -1.

    Yeah, enfin un peu de standardisation dans ce vaste fout*ir qu'est Linux ! Je suis pour la diversité et le choix laissé à l'utilisateur mais y'a un moment ou c'est trop.

    • [^] # Re: CooL

      Posté par  (site web personnel) . Évalué à 0.

      Bof.
      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  (site web personnel) . Évalué à 3.

    J'aurai une question. Il me semble que windows possède un système équivalent (COM+ ?) ; j'aurai aimer savoir à quel niveau D-BUS se situe par rapport à celui-ci, en terme de qualité notamment. Ce n'est pas que la réponse puisse me faire quitter mon système libre, mais le technicien que je suis aime bien savoir ce qui se passe à côté (d'ailleurs ma question vaut aussi pour les autres OS/environnements).

    Merci d'avance.

  • # D-Bus, Bonobo & co.

    Posté par  . Évalué à 10.

    On ne peut pas réellement parler de remplacement de Bonobo par D-Bus dans le cadre de GNOME.

    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.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.