Quelque chose de plus élevé et plus complet que des tuyaux / sockets?
7 Réponses :
pour la communication interprocession, D-Bus est le mécanisme de niveau supérieur standard. GTK et QT ont à la fois des liaisons pour D-bus, la plupart des environnements de bureau (ou du moins Gnome et KDE) exposent divers services via D-bus et de nombreuses applications de bureau peuvent être contrôlées via une interface D-BUS. Le bus système est également utile pour déterminer diverses informations de faible niveau sur le système à l'aide de services système standard.
KDE4 (construit sur Qt4) comprend également une technologie appelée KParts, souvent comparée à la fenêtre de la fenêtre.
"Pour la communication interprocite, D-Bus est le mécanisme standard." Il est? Les sockets, la mémoire partagée, les files d'attente de messages et les sémaphores sont ce que je dirais si vous lui avez demandé que les mécanismes de communication interprocessé standard de tout environnement de POSIX étaient.
D-Bus est de niveau supérieur à celui des mécanismes élémentaires que vous liste, plus comparables à COM / DCOM et sur Linux (tous les autres hérités de nombreuses autres versions de Unix-D-Bus sont construites sur ce niveau inférieur. des mécanismes bien sûr).
Vous pouvez écrire des contrôleurs de Pigin IM qui fonctionnent via un bus D-bus au lieu d'un plugin porcin. Exécutez DBus-Monitor --Session et vous pouvez voir Pigdin mettant tout dans vos conversations sur le bus D-bus.
J'ai légèrement ajusté cette phrase pour clarifier que j'étais signification de l'infrastructure de niveau supérieur de WRT (comme c'est la question de la question). En outre, D-Bus est de plus en plus populaire avec des outils de niveau inférieur, tels que PolicyKit et Hal.
De plus, en outre, la plupart de chaque application KDE dispose d'une interface D-BUS (certaines interfaces sont assez vastes). La liste des projets qui l'utilisent est incroyablement incomplète.
Non ce n'est pas le cas. "Devenir de plus en plus populaire" n'est pas "standard".
"Devenir de plus en plus populaire" était en ce qui concerne les outils de niveau inférieur. Le mouvement pour remplacer les applications SUID / GUID sur Linux exploite généralement le bus système de D-Bus pour atteindre ces remplaçants. Desktop Linux, d'autre part, avaient déjà une adoption généralisée de D-bus, même devenue en 2009. Il n'a pas remplacé les sockets / tuyaux, mais ce n'est pas censé. Diverses plates-formes spécialisées ont souvent leurs propres mécanismes, mais ceux-ci sont généralement dépendants de la plate-forme et seraient encore plus difficiles à appeler le mécanisme IPC de niveau supérieur de niveau supérieur de «standard». Ne supposez pas que toutes les normes sont de jure.
Dbus est plus comme DDE que com. C'est bien pour ce que ça fait.
Il y a la technologie XPCOM de Mozilla, modèle d'objet de composant Cross Platform. Sorte de semblable à com ou à dcom conceptuellement.
ici est une liste des programmes relativement peu nombreux utilisés de la D-bus
Le projet mono saute à l'esprit. Surtout parce que le CLR / .NET est le nouveau contenu, COM, com a été vendu initialement comme des objets compatibles binaires indépendants.
Je suppose dcom (c'est-à-dire com avec un fil plus long) serait .NET Remoting? Ou peut-être certains services Web avec sérialisement objet. Je crois que Mono soutient les deux.
Oui, il y a beaucoup de choses, mais il n'y en a pas comme "standard" comme com / dcom. Au moins, dans Windows, COM / DCOM est utilisé par des éléments "Windowsish" et d'autres mécanismes RPC sont utilisés par des trucs non "Windowsish".
Linux n'a rien de tel que cela nécessite des choses qui nécessitent des protocoles RPC de niveau supérieur, utilisent généralement tout ce que leur langue fournit, ou une bibliothèque spécifique qui convient le mieux aux besoins d'une application. Des exemples de ce serait RMI dans Java, le module "Pyro" de Python, etc., qui fournira (certaines) parité fonctionnelle avec DCOM.
Corba est un peu lourd, mais certaines personnes l'utilisent apparemment.
Beaucoup d'applications font rouler leurs propres bibliothèques RPC. Ne faites pas cela à moins que vous ne soyez pas obligé, c'est méchant.
Le Sun RPC est-il la même chose comme com / dcom?
ONC RPC est plus sur le pair avec DCE / RPC ou MSRPC . Son IDL est beaucoup plus simple et il a moins de fonctionnalités. distribué com est basé sur MSRPC pour la communication, mais elle gère de nombreuses choses complexes au-dessus de ce niveau, tel En cas de mise en cache d'objet proxy pour éviter addref et QueryInterface Tours arrondis, Pinging pour la collecte des ordures, la gestion de la mémoire spécifique à une
Linux n'a rien de tel que celui-ci : Je dirais dbus est assez proche: les applications peuvent exposer des méthodes et des événements RPC, vous pouvez intégrer ces méthodes, puis les appeler à distance. Beaucoup d'applications roulent leurs propres bibliothèques RPC. Ne faites pas cela à moins que vous ne soyez pas obligé, c'est méchant Je vois définitivement le point. D'autre part, je dirais que des choses comme Emacs et Gimp ont de jolies bibliothèques RPC. Je suppose que la demande la plus compliquée est la plus compliquée, plus elle mérite son propre mécanisme RPC!
DCOM est disponible sur Linux. Ce n'est pas "la façon de faire des choses" de la Linux ", mais hé, si vous voulez" comme DCOM, mais Linux ", utilisez ensuite DCOM sur Linux et avez-vous fait ...
... une autre alternative à considérer peut-être Java RMI et
Il est également intéressant de voir les questions liées:
Y at-il un équivalent à COM sur les systèmes * nix? Dans le cas contraire, ce qui était l'approche * nix pour réutilisabilité?
analogique de la programmation COM sous Linux / UNIX
Merci à tous - c'était à peu près mon sentiment que les choses se trouvaient. J'ai accepté la réponse de @ Markr car il semblait de relever les choses bien.