DBUS est si complique que KDE a fait un QDBUS pour retrouver la simplicite et la puissance de DCOP!
l'implémentation de référence de D-Bus est volontairement bas-niveau pour faciliter l'écriture de wrappers. De même GNOME a développé dbus-glib et maintenant GDBus (intégré à la GLib).
QDBus est un wrapper de libdbus, pas une réimplémentation.
mauvais exemple
J'attend le nom de technos KDE que Gnome a reutilise dans les 5/6 ans
Facile, WebKit. GNOME ne rechigne pas à utiliser une technologie issue de KDE si elle est neutre.
Si WebKit a connu un plus grand succès que son prédécesseur KHTML, c'est principalement du au fait qu'Apple a pris soin de découpler WebCore de Qt et KDElibs.
Si GNOME emprunte moins de technologies à KDE que l'inverse, c'est principalement dû au fait (que j'ai déjà souligné auparavant) que KDE ne propose JAMAIS d'implémentation générique ou essaie toujours d'imposer un truc FINI avant même de discuter des choix.
La meme question a ete pose sur le blog de Aaron et la aussi les reponses ne sont pas legions ou du style de la tienne, a cote.
Sur le blog d'Aaron, Dan Winship a rappelé que lui et Matthias Clasen avait tenté de discuter la proposition de "status notifiers" pour se voir opposer une fin de non recevoir et bizarrement Aaron n'a pas su répondre.
Au passage que le projet Gnome ne veuille pas prendre l'implementation de la norme qui etait en train d'etre cree et d'etre utilise par tous les projets autre que Gnome
C'est un non-sens total, certes GNOME n'est pas obligé d'utiliser l'implémentation de référence (et vice-versa) mais tu ne peux pas arriver avec une implémentation finie, vendor-specific et balancer un "c'est la norme, point barre".
Les mecs de KDE ont refusé de discuter des choix de conception (un comble pour une proposition de spécification), parce qu'ils avaient déjà un truc en place et estimaient qu'ils avaient déjà résolus tout les problèmes.
Quand on veut démarrer une norme, soit on accepte de partir d'une feuille blanche (ce qui n'empêche de s'inspirer de l'existant comme avec DBus/DCOP), soit on propose une implémentation de référence que tout le monde peut bidouiller. Dans tout les cas, ça implique de discuter des choix de conceptions et de faire des compromis, quitte à casser des choses existantes mais les gars de KDE n'était pas prêts pour ça.
[^] # Re: Lire le billet original de Dave Neary (encore lui !) avant
Posté par GeneralZod . En réponse au journal Gnome vs Canonical: l'avis de Aaron Seigo. Évalué à 3.
Facile, WebKit. GNOME ne rechigne pas à utiliser une technologie issue de KDE si elle est neutre. Si WebKit a connu un plus grand succès que son prédécesseur KHTML, c'est principalement du au fait qu'Apple a pris soin de découpler WebCore de Qt et KDElibs. Si GNOME emprunte moins de technologies à KDE que l'inverse, c'est principalement dû au fait (que j'ai déjà souligné auparavant) que KDE ne propose JAMAIS d'implémentation générique ou essaie toujours d'imposer un truc FINI avant même de discuter des choix.
Sur le blog d'Aaron, Dan Winship a rappelé que lui et Matthias Clasen avait tenté de discuter la proposition de "status notifiers" pour se voir opposer une fin de non recevoir et bizarrement Aaron n'a pas su répondre.
C'est un non-sens total, certes GNOME n'est pas obligé d'utiliser l'implémentation de référence (et vice-versa) mais tu ne peux pas arriver avec une implémentation finie, vendor-specific et balancer un "c'est la norme, point barre". Les mecs de KDE ont refusé de discuter des choix de conception (un comble pour une proposition de spécification), parce qu'ils avaient déjà un truc en place et estimaient qu'ils avaient déjà résolus tout les problèmes.
Quand on veut démarrer une norme, soit on accepte de partir d'une feuille blanche (ce qui n'empêche de s'inspirer de l'existant comme avec DBus/DCOP), soit on propose une implémentation de référence que tout le monde peut bidouiller. Dans tout les cas, ça implique de discuter des choix de conceptions et de faire des compromis, quitte à casser des choses existantes mais les gars de KDE n'était pas prêts pour ça.