DBus is an IPC protocol, it is the first thing the specification[0] mentions, there isn't any way where it would make sense for it to be used in-process nor the

DBus is an IPC protocol, it is the first thing the specification[0] mentions, there isn't any way where it would make sense for it to be used in-process nor the spec provides for such functionality. Some higher level library could potentially provide an API for exposing and consuming (object) interfaces that can be accessed either in-process or out-of-process, though only the latter would really be using DBus and the former would bypass it (and both would be only really usable only by users of that library, not anything using DBus). DCOP is/was also an IPC protocol, though much simpler than DBus as it was essentially about passing arbitrary data between processes with some IDs attached (the higher level API did pretend that they were objects and method calls but the -still public- lower level API worked in terms of string identifiers and data streams), which makes it unsuitable for a cross-language ABI. KPart however (which is still being developed and part of KDE) is sort of a relative idea to COM in that it is really something similar (in concept) to ActiveX, so it could handle some uses (though it lacks the genericness of COM), except it being C++ based also makes it impractical for a cross-language ABI - which is the entire reason COM was brought up (and why IPC approaches like DBus and DCOP aren't relevant to what was discussed). [0] https://dbus.freedesktop.org/doc/dbus-specification.html https://dbus.freedesktop.org/doc/dbus-specification.html