On Jul 5, 2012, at 9:11 PM, Dirk Jagdmann wrote:
> Both use cases involve a sender and multiple receiver scenario. I don't need to
> send these requests to a different computer, so a local message bus is
> sufficient. In the KDE and Gnome world
> http://www.freedesktop.org/wiki/Software/dbus would be a natural choice, but I
> don't think that Wireshark uses dbus on Windows or OsX.
Wireshark doesn't use D-Bus on any platform. It could, in theory, use it on Windows or OS X, but, in practice, that might not be as useful as using a different technology, such as Apple Events/AppleScript on OS X or $TECHNOLOGY (ActiveX?) on Windows.
> So I'd like to get opinions what kind of technology for the inter process
> communication I should use, that will work on Windows, OsX and the Linux/BSD
> world. Did someone start such a project? Would we prefer a certain existing
> protocol/library? I could also think about simply using a multicast socket and
> send messages across. This would without further effort allow Wireshark control
> from different hosts.
There's no reason in principle not to have multiple mechanisms. I don't think D-Bus, Apple Events, ActiveX, etc. are cross-machine - this page:
http://www.freedesktop.org/wiki/IntroductionToDBus
says
D-Bus is an inter-process communication mechanism—a medium for local communication between processes running on the same host. (Inter-host connects may be added in the future, but that is not what D-Bus is meant for).
and I think Apple Events pass over Mach messages (for which I think cross-machine transport may have existed at one point, but I don't think OS X supports it in any way, shape, or form), and while there *is* DCOM for cross-machine COM, I don't think ActiveX is cross-machine, either, so perhaps some cross-machine mechanism would be useful (CORBA-based, or just "roll your own"?).
If we export some kind of "remote control" mechanism, ideally it could plug into various native mechanisms, including D-Bus, Apple Events, and whatever the Technology Of The Week is on Windows.
