Es gibt shared memory, mailboxen, pipes und sockets zur Prozessinterkommunication (IPC).
Das ist nicht direkt vergleichbar, das sind verschieden Schichten im Kommunikationsmodell.
Diese Technologien sind Transportmechanismen, kein IPC. Das muss immer darauf aufsetzten entwickelt werden. Die Frage ist, ob man das immer selbst und applikationsspezifische machen will, oder auf eine standardisierte Lösung setzt.
Kommunikation zwischen Programmen unterschiedlicher Hersteller funktionieren soll, geht ohnehin nichts an einem gemeinsamen Protokoll und begleitender Konventionen (z.B. wie man den Socket findet).
Der Zweck von D-Bus ist das zur Verfügungstellen von aufrufbarer Funktionalität, also zur Kooperation von Programmen, nicht zum reinen Datenaustausch.
Und das gibt es auf allen gängigen Betriebssystemen.
D-Bus ist ja keine neue Transporttechnologie, sondern ein darauf aufsetztender Mechanismus. Es ist demnach überall umsetzbar, wo es Transporttechnologien gibt, die den nötigen Ansprüchen genügen. Zum Beispiel Sockets (bevorzugt lokale), Named Pipes, etc.
Ich verwende Qt, weil ich alle gängigen Betriebssysteme unterstützen können möchte.
QtDBus ist auf allen Desktopplattformen verfügbar, Embedded auch auf Linux (da ist für Qt ohnehin wenig Unterschied).
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 26. Apr 2015 um 10:09.
Pipes, Sockets, Shared Memory sind ganz klar IPC, ersten beiden sogar klassiche aus dem Unix-Umfeld Jahrzehnte alt. Auch D-Bus ist IPC nur mit definierten Protokoll. Ich frage mich ernsthaft was du mit diesem Posting sagen wolltest.
Ich hatte zwar den Quote Tag nicht richtig geschlossen, aber ich denke es war durchaus erkennbar, wo das Zitat des Vorkommentars endete und wo mein Kommentar begannt.
Aber nochmal explizit: D-Bus ist eine Schicht höher als die vom Vorposter genannten Transporttechnologien. Es definiert Protokoll und Mechanismen, die die Kommunikation zwischen Programmen unterschiedlicher Hersteller ermöglichen.
Das Auflisten von Tranporttechnologien macht keinen Sinn im Kontext von ohnehin darauf aufbauender Schichten.
Es ist vielleicht klarer, wenn man das im Kontext anderer weit verbreiteter Lösungen betrachtet: "Warum ich HTTP (momentan noch) nicht verwenden würde, es gibt ja Shared Memory, Sockets und Pipes".
HTTP exisitier ja nicht im Vakuum, es baut auf der universellen Existenz von Sockets auf. Aber wenn jeder Hersteller ein eigenes Protokoll einsetzen würde, könnten nur Produkte dieses Herstellers kommunizieren. Der Wert von HTTP liegt nicht in der Bereitstellung eines Kommunikationskanals, sondern in der Standardisierung desselben.
Alternativ zu D-Bus könnte man also auch HTTP über lokale Sockets laufen lassen und einmal systemweit und pro Usersession je einen darauf aufbauenden Webserver laufen lassen, der dann die Kommunikation zwischen den Programmen mittels REST oder ähnlichem ermöglicht.
Von Fluxkompensator am Mo, 27. April 2015 um 07:55 #
> D-Bus ist IPC nur mit definierten Protokoll.
D-Bus macht auch IPC. Aber nicht nur IPC sondern auch RPC, Introspection, Service Discovery, Multicast, Object Lifecycle, Service Activation, usw. usf. Alles in einem API, verfuegbar fuer so ziemlich jede Sprache, genutzt von ziemlich viel Software.
Pipes, Sockets, Shared Memory sind ganz klar IPC, ersten beiden sogar klassiche aus dem Unix-Umfeld Jahrzehnte alt. Auch D-Bus ist IPC nur mit definierten Protokoll. Ich frage mich ernsthaft was du mit diesem Posting sagen wolltest.
Ich hatte zwar den Quote Tag nicht richtig geschlossen, aber ich denke es war durchaus erkennbar, wo das Zitat des Vorkommentars endete und wo mein Kommentar begannt.
Aber nochmal explizit: D-Bus ist eine Schicht höher als die vom Vorposter genannten Transporttechnologien.
Es definiert Protokoll und Mechanismen, die die Kommunikation zwischen Programmen unterschiedlicher Hersteller ermöglichen.
Das Auflisten von Tranporttechnologien macht keinen Sinn im Kontext von ohnehin darauf aufbauender Schichten.
Es ist vielleicht klarer, wenn man das im Kontext anderer weit verbreiteter Lösungen betrachtet: "Warum ich HTTP (momentan noch) nicht verwenden würde, es gibt ja Shared Memory, Sockets und Pipes".
HTTP exisitier ja nicht im Vakuum, es baut auf der universellen Existenz von Sockets auf.
Aber wenn jeder Hersteller ein eigenes Protokoll einsetzen würde, könnten nur Produkte dieses Herstellers kommunizieren.
Der Wert von HTTP liegt nicht in der Bereitstellung eines Kommunikationskanals, sondern in der Standardisierung desselben.
Alternativ zu D-Bus könnte man also auch HTTP über lokale Sockets laufen lassen und einmal systemweit und pro Usersession je einen darauf aufbauenden Webserver laufen lassen, der dann die Kommunikation zwischen den Programmen mittels REST oder ähnlichem ermöglicht.
> D-Bus ist IPC nur mit definierten Protokoll.
D-Bus macht auch IPC. Aber nicht nur IPC sondern auch RPC, Introspection, Service Discovery, Multicast, Object Lifecycle, Service Activation, usw. usf. Alles in einem API, verfuegbar fuer so ziemlich jede Sprache, genutzt von ziemlich viel Software.