Ich kenne Dbus nicht genauer aber vielleicht ist es ähnlich wie SOAP und die Daten werden doch letztlich als XML verpackt übertragen? Nein. D-BUS ist ein schnelles IPC Protokoll mit anfänglicher RPC Unterstützung. SOAP ist ein XML basierendes RPC Protokoll. Bie D-BUS wird so wenig wie möglich mit den Daten beim Übertragen angestellt, damit's eben schnell ist. Weiß nicht ob das für D-BUS auch zutrifft, aber bei DCOP wurde nicht mal die Byteorder geändert. Stattdessen gab's ein kleines Flag im Protokollheader, das darüber Aufschluss gab. Somit muss im IPC Fall nix konvertiert werden und im RPC Fall gehts trotzdem noch über Plattformgrenzen hinweg.
Von Kevin Krammer am Sa, 11. November 2006 um 19:58 #
Der D-Bus Daemon muß nur die Informatione dekodieren, die er zum Weiterleiten benötigt, d.h. im Falle eines Methodenaufrufs nur die Zielverbindung. An welches Objekt das dann am Ziel weitergeleitet wird, ist bereits Teil der Zielapplikation, aber üblicherweise schon noch in der libdbus.
Im Falle eines Signals, das ja an alle geht, wird vermutlich sogar nur diese Information, also Art der Nachricht, dekodiert.
Ich bin mir jetzt ziemlich sicher, daß in keinem Fall an der Nachricht selbst Änderung vorgenommen werden.
Sehr schön, wenn die Entwickler dann noch, bis zur nächsten Version, eine elegante Methode für den Aufruf über Rechnergrenzen hinweg finden, bin ich sogar extrem begeistert.
Das könnte der Standard schlechthin werden.
Habe das mal just via Python getestet. Also mir gefällt's.
Von Kevin Krammer am Sa, 11. November 2006 um 19:23 #
Das geht ansich schon, wenn man als Transportschicht TCP benutzt. Das Problem ist in diesen Fällen mehr die Authentifizierung und sichere, im Sinne von nicht einsehbare, Übertragung.
Ja eben. Also gscheite Authentifizierung und verschlüsselte Übertragung über TCP-Sockets. Das wär noch EXTREM cool. Ist das echt so schwer zu implementieren, oder hat das bis jetzt einfach niemand implementieren wollen?
Von Kevin Krammer am Sa, 11. November 2006 um 19:54 #
Das hat einfach bisher noch niemand implementiert, weil die hauptsächliche Verwendung in erster Linie über lokale Unix Domain Sockets geht.
Ich glaube, daß die TCP Implementierung auch nur deswegen gemacht wurde, um sicher zu gehen, daß alle beteiligten Komponenten keine versteckten Annahmen über die Art des Datentransports machen, bzw. um das zu erkennen.
Eine meiner Meinung nach ziemlich wahrscheinliche Erweiterung ist eine Transportschicht über X11, d.h. damit eine Remote X11 Applikation auf den D-Bus Daemon der X11 Session zugreifen kann. In diesem Fall hat X11 praktisch die Authentifizierung gemacht und X11 kann zB über SSH getunnelt werden.
Eine Variante ist, eine Socket hie und da an ein nc zu bammeln. Sollte dann aber wirklich nur über ein vertrauenswürdiges lan gehen. Habe ich selbst vor vielen Jahren mal genutzt, um ein an einem anderen Rechner angeschlossenes Messgerät auszulesen. Das ging alles noch seriell, bei usb gibt es heutzutage die Probleme zum Glück nicht mehr.
Von Kevin Krammer am Mo, 13. November 2006 um 17:54 #
Von Kopplung ist auch nicht die Rede.
Es geht darum, einer Applikation, die zwar am selben X Server wie die Desktopsession angezeigt wird, aber auf einem anderen Rechner läuft, Zugriff auf den Sessionbus zu ermöglichen, ohne daß ein weiteres Protokoll getunnelt werden muß.
Von Kevin Krammer am So, 12. November 2006 um 13:25 #
Leider nein.
Es gab kürzlich einen Thread, der sich mit der entsprechenden Konfiguration des Daemon befasst hat: http://lists.freedesktop.org/archives/dbus/2006-November/006331.html
Vermutlich recht es für die Clients, die Adreßvariablen entsprechend zu setzen, d.h. tcp:host:port oder ähnlich
Von DarkVision am Sa, 11. November 2006 um 21:39 #
>> Obwohl D-Bus erst jetzt Version 1.0.0 (Codename »Blue Bird«) erreicht hat, sind Protokoll und API laut FreeDesktop.org bereits seit Jahren erprobt und werden nun stabil gehalten.
Naja... ich kann mich an ein "DBUS_API_SUBJECT_TO_CHANGE" errinnern was gerade bei GNOME hier und da für ein paar patches beim compillieren erforderlich machte. Beim Wechsel von DBus 0.62 auf 0.9x fielen die QT3-bindings unter den Tisch und der QT4-QT3-Backport ist ein Witz... (das was auf freedesktop bereitsteht läuft hier nicht mit HAL/KDE 3.5.x, die QT3-bindings von http://ranger.befunk.com/fink/ funktionieren besser). Aber dazu gab es schon einige Postings in div. Newsgroups. Hoffentlich wird das mit der 1er Version besser.
Von Kevin Krammer am So, 12. November 2006 um 13:29 #
Das DBUS_API_SUBJECT_TO_CHANGE war während der Entwicklung eine Art Erinnerung, die der Entwickler durch ein entsprechendes define zur Kenntnis nehmen mußte.
Wurde natürlich für dein 1.0 Release entfernt, ab hier gibt es die nötige Sicherheit, daß sich nichts mehr verändern wird, allenfalls kompatibel erweitert.
Von DarkVision am So, 12. November 2006 um 21:47 #
Ich bezog mich damit auf die Aussage das die API schon seit Jahren erprobt und stabil sei... Seit 0.60 wurde so einiges geändert. Musste ich gerade erst wieder feststellen als ich avahi neu kompilliert hab. Dort gab es einen check auf DBus>=60 der mit der 1er Version auch nicht mehr funktionierte. Die API mag erprobt sein, aber keinesfalls seit Jahren stabil. Allerhöchstens seit 0.62++ und die Version stammt vom Juni diesen Jahres.
Von DarkVision am So, 12. November 2006 um 22:11 #
P.S. Trotz diversen Problemen mit API und Bindings ist DBus eine gute Sache und ich bin mir sicher mit der 1er wird alles besser (aber das hofft man ja immer ). Nachdem auch KDE4 komplett auf DBus setzt kann es so falsch nicht sein.
Von DarkVision am So, 12. November 2006 um 09:52 #
Hast Du überhaupt Anwendungen am laufen die DBus einsetzten? Wenn nein, warum sollte das System langsamer werden? Wenn ja, Gnome? Da hilft auch alles meckern nichts, Gnome 2.16+ benötigt DBus genauso wie auch KDE4. Ohne Beweise nur ein Trollposting...
Ja echt dumm. Auch Windows war ein square-wheel denn Apple hatte ja mit system 6 bereits ein grafisches Betriebssystem erfunden. Deshalb ist Apple jetzt auch Marktführer und hält über 30% von MS, während Bill kurz vor der Pleite steht. Wenn gtk einen message-bus hat und KDE dann ist es natürlich sinnlos einen message-bus zu entwickeln der qt- und glib-bindings für beide bereit stellt. Besser wäre es natürlich weiterhin zwei völlig getrennte systeme zu nutzen die völlig inkompatibel sind.
Apple hat 30% von MS? Woher hast du die Info her? Ich glaube, dass ist eher umgekehrt. Ausserdem halte ich ein System für verschiedene Bindings geeigneter als Inkompatibilität.
Von Kai F. Lahmann am So, 12. November 2006 um 23:30 #
zu der Zeit, als Apple fast pleite war, hielt afaik Bill Gates persönlich einen Teil der Aktien. Über ihn wird ja auch gesagt, dass er selbst einen Mac benutzt ;).
Dir ist schon bewusst, dass sich Anforderungen an Protokolle und APIs innerhalb von 15 Jahren gerne mal ändern, auch wenn die Grundidee vielleicht diesselbe ist? Bei 9P scheint es auch eher um Dateitransfer zu gehen (und alles was man bequem darauf abbilden kann) und nicht um Methodenaufrufe.
Von Christophorus am So, 12. November 2006 um 17:28 #
Ein Square-wheel? Wenn ich mich jetzt über diesen peinlichen Anglismus aufrege, werde ich sicher ganz schnell in die nationalistische Ecke gestellt... Nebenbei bemerkt: "Plan 9 Filesystem Protocol" (Zitat aus Wikipedia). Ich glaube, da hast du den Wikipedia-Artikel etwas missinterpretiert bzw. diesem Protokoll mehr Fähigkeiten zugesprochen, als es anscheinend hat.
Von Wer lesen kann... am Mo, 13. November 2006 um 12:06 #
The file is a central metaphor of Plan 9, and many things are represented as files, including windows, network connections, processes, and almost anything else available in the operating system.
ja mit 9p kann man prima querien was es so gibt und die infos aehnlich sysfs organisieren,aber wie wird man von aenderungen benachichtigt? staendig pollen?
Von Enrico Weigelt, metux IT servi am Mo, 31. August 2009 um 12:41 #
Nein, indem man einfach den Stream ausliest (TRead) abschickt. Eine Antwort kommt erst dann zurück, wenn wirklich Daten zum Lesen da sind. So trivial kann das Leben sein ;-o
Komplexe RPCs braucht man idR. nur, wenn man auf der Ideologie festhängt, daß Datenzugriffe immer über procedures/methoden laufen müßten ;-o
Also ich arbeite täglich mit XML und bin auch überzeugt von den Fähigkeiten des Format und vielem was dran hängt. Aber als Konfiguration für einen Daemon in Unix, da sehe ich keinen Vorteil. Immerhin wird hier noch stark mit der Konsole gearbeitet, auch wenn es nicht immer sein müsste. Und XML auf der Konsole macht einfach keinen Spass.
Ist die Konfiguration denn so umfassend das es nötig ist einen Haufen ASCII Müll zu produzieren nur um klar zu machen das sich z.B. die Angabe auf den Bereich Netzwerk bezieht ? Da langt doch auch folgendes: # Networking # listen 0.0.0.0 # listen port xxx
Den einzigen Vorteil den ich sehe wäre eine Validierung und das editieren mit Autovervollständigung via Schema. Aber ist es das wert ? Eine andere Sache wäre es wenn man verschiedene Provider/Dienste konfigurieren kann, wenn die Konfiguration es vorsieht das vieles rausgelassen oder reingenommen werden kann macht es wieder Sinn (wie z.B. bei JBoss).
Grüße Felix, der dem Thema XML als Konfiguration unter Unix noch etwas unentschlossen gegenüber steht.
XML ist eine technik/ein format. Nicht mehr nicht weniger. Es hat wie viele andere dinge vor- und nachteile. Es ist mir keine technologie bekannt, bei der man immer nur gewinnt.
Dein bespiel ist gut gewaehlt, denn bis auf die validierung der syntax bietet XML hier keinen einzigen vorteil. Einen scanner/parser fuer eine so simple grammatik zu schreiben ist ebenfalls sehr leicht und ich spare mir das hinzulinken einer fetten XML lib, die auch noch vieles mitbringt was ich nicht brauche (encodings zB).
> Einen > scanner/parser fuer eine so simple grammatik zu schreiben...
Ja, uns jedesmal neu für jedes poplige Programm - genialer Lösungsansatz. Was krallt ihr euch immer an den paar Zeichen mehr fest? Ein systemübergreifender XML-basierter Ansatz mit API, usw. ist doch nix schlechtes, Stichwirt elektra.
Das wäre wirklich ein Grund. Wenn man z.B. verschiedene Policies definiert und diese dann wonders über eine ID einbindet. Da bietet sich dann auch die Möglichkeit Parameter zu übergeben, die Policy zu erweitern oder sie beim parsen aus dem Kontext heraus zu interpretieren.
weiterhin ist es auch fuer command line leute toll,da man z.b. das da tun kann: xmlstarlet sel -t -v '/networking/@port' config.xml statt einem grep bei dem man nicht nur ueber die struktur sondern auch ueber die syntax nachdenken muss!
und eine kleine xml parser lib ist nun auch nicht soo gross selbst glib kann ein xml subset parsen oder halt tinyxml.
XML wird nur fuer die Konfigurationsdateien verwendet (/etc/dbus), das Protokoll hat mit XML nichts zu tun.
Nein. D-BUS ist ein schnelles IPC Protokoll mit anfänglicher RPC Unterstützung. SOAP ist ein XML basierendes RPC Protokoll. Bie D-BUS wird so wenig wie möglich mit den Daten beim Übertragen angestellt, damit's eben schnell ist. Weiß nicht ob das für D-BUS auch zutrifft, aber bei DCOP wurde nicht mal die Byteorder geändert. Stattdessen gab's ein kleines Flag im Protokollheader, das darüber Aufschluss gab. Somit muss im IPC Fall nix konvertiert werden und im RPC Fall gehts trotzdem noch über Plattformgrenzen hinweg.
Im Falle eines Signals, das ja an alle geht, wird vermutlich sogar nur diese Information, also Art der Nachricht, dekodiert.
Ich bin mir jetzt ziemlich sicher, daß in keinem Fall an der Nachricht selbst Änderung vorgenommen werden.
Das könnte der Standard schlechthin werden.
Habe das mal just via Python getestet. Also mir gefällt's.
Danke.
Ich glaube, daß die TCP Implementierung auch nur deswegen gemacht wurde, um sicher zu gehen, daß alle beteiligten Komponenten keine versteckten Annahmen über die Art des Datentransports machen, bzw. um das zu erkennen.
Eine meiner Meinung nach ziemlich wahrscheinliche Erweiterung ist eine Transportschicht über X11, d.h. damit eine Remote X11 Applikation auf den D-Bus Daemon der X11 Session zugreifen kann.
In diesem Fall hat X11 praktisch die Authentifizierung gemacht und X11 kann zB über SSH getunnelt werden.
Es geht darum, einer Applikation, die zwar am selben X Server wie die Desktopsession angezeigt wird, aber auf einem anderen Rechner läuft, Zugriff auf den Sessionbus zu ermöglichen, ohne daß ein weiteres Protokoll getunnelt werden muß.
Es gab kürzlich einen Thread, der sich mit der entsprechenden Konfiguration des Daemon befasst hat:
http://lists.freedesktop.org/archives/dbus/2006-November/006331.html
Vermutlich recht es für die Clients, die Adreßvariablen entsprechend zu setzen, d.h.
tcp:host:port
oder ähnlich
Naja... ich kann mich an ein "DBUS_API_SUBJECT_TO_CHANGE" errinnern was gerade bei GNOME hier und da für ein paar patches beim compillieren erforderlich machte. Beim Wechsel von DBus 0.62 auf 0.9x fielen die QT3-bindings unter den Tisch und der QT4-QT3-Backport ist ein Witz... (das was auf freedesktop bereitsteht läuft hier nicht mit HAL/KDE 3.5.x, die QT3-bindings von http://ranger.befunk.com/fink/ funktionieren besser). Aber dazu gab es schon einige Postings in div. Newsgroups. Hoffentlich wird das mit der 1er Version besser.
DV
Wurde natürlich für dein 1.0 Release entfernt, ab hier gibt es die nötige Sicherheit, daß sich nichts mehr verändern wird, allenfalls kompatibel erweitert.
DV
Trotz diversen Problemen mit API und Bindings ist DBus eine gute Sache und ich bin mir sicher mit der 1er wird alles besser (aber das hofft man ja immer
DV
Mir kommt es jedenfalls so vor.
mfg bert
DV
Wenn gtk einen message-bus hat und KDE dann ist es natürlich sinnlos einen message-bus zu entwickeln der qt- und glib-bindings für beide bereit stellt. Besser wäre es natürlich weiterhin zwei völlig getrennte systeme zu nutzen die völlig inkompatibel sind.
Ich glaube, dass ist eher umgekehrt.
Ausserdem halte ich ein System für verschiedene Bindings geeigneter als Inkompatibilität.
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild U ] app-accessibility/irony-detector-1.0 [0.9.22] USE="sarcasm cynicism irony heuristics -troll"
Komplexe RPCs braucht man idR. nur, wenn man auf der Ideologie festhängt, daß Datenzugriffe immer über procedures/methoden laufen müßten ;-o
Ist die Konfiguration denn so umfassend das es nötig ist einen Haufen ASCII Müll zu produzieren nur um klar zu machen das sich z.B. die Angabe auf den Bereich Netzwerk bezieht ? Da langt doch auch folgendes:
# Networking
# listen 0.0.0.0
# listen port xxx
Statt:
<networking>
<listen>
<address>0.0.0.0</address>
<port>xxx</port>
</listen>
</networking>
Den einzigen Vorteil den ich sehe wäre eine Validierung und das editieren mit Autovervollständigung via Schema. Aber ist es das wert ? Eine andere Sache wäre es wenn man verschiedene Provider/Dienste konfigurieren kann, wenn die Konfiguration es vorsieht das vieles rausgelassen oder reingenommen werden kann macht es wieder Sinn (wie z.B. bei JBoss).
Grüße
Felix, der dem Thema XML als Konfiguration unter Unix noch etwas unentschlossen gegenüber steht.
XML ist eine technik/ein format. Nicht mehr nicht weniger.
Es hat wie viele andere dinge vor- und nachteile. Es ist mir
keine technologie bekannt, bei der man immer nur gewinnt.
Dein bespiel ist gut gewaehlt, denn bis auf die validierung
der syntax bietet XML hier keinen einzigen vorteil. Einen
scanner/parser fuer eine so simple grammatik zu schreiben
ist ebenfalls sehr leicht und ich spare mir das hinzulinken
einer fetten XML lib, die auch noch vieles mitbringt was ich
nicht brauche (encodings zB).
Der Omega13.
> scanner/parser fuer eine so simple grammatik zu schreiben...
Ja, uns jedesmal neu für jedes poplige Programm - genialer Lösungsansatz. Was krallt ihr euch immer an den paar Zeichen mehr fest? Ein systemübergreifender XML-basierter Ansatz mit API, usw. ist doch nix schlechtes, Stichwirt elektra.
Zur Bus Konfiguration gehören auch Policies, also wer mit wem kommunizieren darf, welche Art von Kommunikation, usw.
Ließe sich vermutlich zwar auch auf ein flaches Format abbilden, verliert dann aber leicht die Zusammengehörigkeit.
Grüße
Felix
weiterhin ist es auch fuer command line leute toll,da man z.b. das da tun kann:
xmlstarlet sel -t -v '/networking/@port' config.xml
statt einem grep bei dem man nicht nur ueber die struktur sondern auch ueber die syntax nachdenken muss!
und eine kleine xml parser lib ist nun auch nicht soo gross selbst glib kann ein xml subset parsen oder halt tinyxml.