4 ms·

D-Bus is for IPC not an ABI. If there was something similar it'd be gobject, but i don't think any language other than Vala speaks it "natively" (and considerin

D-Bus is for IPC not an ABI. If there was something similar it'd be gobject, but i don't think any language other than Vala speaks it "natively" (and considering how much Gtk cares about backwards binary compatibility, i don't think it'd be a good idea to target it anyway).

pjmlp 5y ago
It can run in-proc and fits the scenarios being given on previous comment. I remeber Bonobo, DCOP and KPart days, so I know pretty well what D-Bus is capable of. In micro-kernels the IPC infrastructure is the userspace ABI, as it is the only way to call into OS services, beyond the little glue library to make it possible to do so.
- marwis 5y ago
  Where did you see in-proc D-Bus? It would be wildly inefficient compared to COM/gobject anyway.
  - pjmlp 5y ago
    COM nowadays runs mostly out of process unless you like crashing the whole application, hence the reference to nano-COM for in-proc APIs that are basically OO ABI. That is why any modern Windows has plenty of COM Surrougate processes running at any given time. As for D-BUS, I stand corrected, I though it had such optimization in place, just as other mechanisms offer.
    - marwis 5y ago
      There's a ton of new in-proc COM usage through WinRT.
      - pjmlp 5y ago
        You mean the market failure that no one wants to use any more, even those of us that were early adopters? I am betting in 2 to 3 years we will have yet another reboot from WinUI and WinAppSDK. How things are, I wouldn't be surprised with Blazor with WebWidget2 as the new cool desktop UI.
- badsectoracula 5y ago
  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
  - pjmlp 5y ago
    2h30m before of your comment, I already acknowledged my mistake, you could have saved yourself some typing.
    - badsectoracula 5y ago
      Oops, it was in another reply and i didn't notice it.

pjmlp 5y ago

It can run in-proc and fits the scenarios being given on previous comment. I remeber Bonobo, DCOP and KPart days, so I know pretty well what D-Bus is capable of. In micro-kernels the IPC infrastructure is the userspace ABI, as it is the only way to call into OS services, beyond the little glue library to make it possible to do so.

marwis 5y ago
Where did you see in-proc D-Bus? It would be wildly inefficient compared to COM/gobject anyway.
- pjmlp 5y ago
  COM nowadays runs mostly out of process unless you like crashing the whole application, hence the reference to nano-COM for in-proc APIs that are basically OO ABI. That is why any modern Windows has plenty of COM Surrougate processes running at any given time. As for D-BUS, I stand corrected, I though it had such optimization in place, just as other mechanisms offer.
  - marwis 5y ago
    There's a ton of new in-proc COM usage through WinRT.
    - pjmlp 5y ago
      You mean the market failure that no one wants to use any more, even those of us that were early adopters? I am betting in 2 to 3 years we will have yet another reboot from WinUI and WinAppSDK. How things are, I wouldn't be surprised with Blazor with WebWidget2 as the new cool desktop UI.
badsectoracula 5y ago
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
- pjmlp 5y ago
  2h30m before of your comment, I already acknowledged my mistake, you could have saved yourself some typing.
  - badsectoracula 5y ago
    Oops, it was in another reply and i didn't notice it.