Status of dbus-python

[Lawrence D'Oliveiro]

On Wed, 28 Mar 2018 10:19:05 +0200, Alan Martinovic wrote:

> Wow, you really invested much into documentation and
> provide lots of usage examples, bravo :)

Thank you. :)

> It seems like a fairly new project, how come that you've
> based it on libdbus?

Because that was the reference D-Bus implementation, and the existing
Python wrapper I had been using (dbus-python) was based on it.

>     (this is just me trying to get an understanding of the d-bus
> realm, I've mostly encountered blog posts saying libdbus is burdened
> by legacy architectural decisions and hard to use)

So I keep hearing. But while that might apply to client code written in
C, I didn’t find it that hard. It has this callback system to let you
hook it into your event loop, and I was able to interface that to
asyncio without too much trouble.

And my Python wrapper seems to be fairly straightforward to use, as
hopefully the examples make clear (feel free to offer a second opinion
on that).

Of course, I haven’t looked in detail at any other D-Bus library...

By the way, I know GLib/GTK has its own gdbus library, but here
<https://github.com/ldo/glibcoro_examples/blob/master/dbus_signal_listener>
is an example of using my libdbus wrapper with the GLib/GTK event loop.
For which I also wrote an asyncio adapter
<https://github.com/ldo/glibcoro>.

> Do you know if libdbus (and on top of that your bindings) can use
> kdbus as the underlying server/daemon?
>     (am trying to guess the correct terminology here. By server/daemon
>     I mean the underlying mechanism that actually conveys the
> dbus-messages. kdbus is the faster, kernel based, mechanism as
> opposed the previously used userspace daemon [didn't get the name of
> that one])

As Simon said, kdbus was proposed as a kernel patch and rejected. I
gather the developers are working on a new thing called BUS-1 ...