dbus-rs could use some fresh blood

[diwic]

My motivation for maintaining dbus-rs has slowly declining over the past year or so. The two main reasons are:

1. I don't have a project that actually uses dbus-rs. When I started this binding five years ago, I had grand plans of software I wanted to build on top of these bindings. Life however had other priorities and those grand plans never happened.

2. One of the hardest part when writing Rust is coming up with the best design. Especially so when it comes to dispatching events, which is not Rust's best fit, but an important part of dbus-rs nonetheless. Having people to discuss these things with would help a lot here.

Having a co-maintainer would help a lot both with the over all quality of these bindings, as well as making coding more fun again. Or if this is not an option for you; consider if you can contribute to this library in another way.

Finally - Rust's ecosystem needs production quality bindings to D-Bus and so far, this project has provided them. I'd like it to stay that way.

[snprajwal]

@diwic I don't know how far I qualify to be a co-maintainer of this project, but I'd love to help out in any way I can. I'd be happy to review PRs and test things in my free time. I would not want this project to stall or be retired, because it provides something none of the other current dbus implementations provide - synchronous calls without the overhead of an async runtime.

• rustbus requires writing too much boilerplate to get stuff working
• zbus pulls in async-std/tokio even if blocking connections are used. Furthermore, the blocking API is just a wrapper around the non-blocking async calls, which bloat the binary with all the state machine logic even if it's not being used in any meaningful way

It would be great to have this project alive and maintained, if only to provide a simple and practical alternative to zbus for smaller projects.

[diwic]

@snprajwal Thanks!

So to sum up the state four years later:

• The bindings are mature and do what most people need them to do
• The project is alive and maintained in the sense that if there is a bug and people post PRs then I will review, merge and release as requested by the bug reporter
• There are some larger issues (marked with "help wanted") that I'm not likely to do myself any time soon
• We still bind to a C library by default, but cross-compiling is easier due to the vendored feature that builds the C code along with the Rust code.
• Contributions are welcome (se readme.md in the root)

For you or anyone else wanting to become a co-maintainer; let me know your visions for the project, see we can agree on some common goals, then start working on those over time to show that you're in it for the long run. Reviewing and testing is welcome but for co-maintainership or even handover I think I'd want someone that drives the project forward.
Does that make sense?

[snprajwal]

Yep, that definitely makes sense. I don't think I'm in a position where I can dedicate time to fully maintain the project - I should have made my intentions clear in the previous comment, sorry about that. I meant to say I'd be happy to share the workload that you and any other future maintainers would have in terms of reviews and general maintenance (deps, breaking changes in versions, etc). Presently, I won't be able to dedicate time to develop new features and drive the project forward from my side, sorry about that!

[zeenix]

• zbus pulls in async-std/tokio even if blocking connections are used. Furthermore, the blocking API is just a wrapper around the non-blocking async calls, which bloat the binary with all the state machine logic even if it's not being used in any meaningful way

@snprajwal Firstly, zbus never had any dep on async-std, so that already shows that you likely didn't do a very thorough evaluation but maybe I'm wrong and you've some numbers to show here? Talking of numbers, in terms of CPU performance, zbus is currently way ahead of dbus-rs. I also feel like you didn't acknowledge the best feature of zbus: it's pure Rust and does not depend on any platform libraries.

Each time I ask someone using dbus-rs instead of zbus these days, there are two answers:

• Something along the lines of "dbus was the first and direct hit when I searched for "dbus" on crates.io". This is the most common answer.
• zbus is bloated (as you claimed). However, in most cases it turns out that people don't bother disabling features they don't need and don't enable any build optimizations (e.g LTO). Also, if they overlook the performance advantage, which clearly overshadows the few hundred extra KBs in your binary (for most use cases).

[snprajwal]

@zeenix happy to see you here :) first off, let me clarify - my point was not an attack on zbus, and I am sorry if it came across that way. I have been using it for my projects, and am very happy with it. The only complaint I had was the increased binary size due to the async runtime, even with the sync API. You are right that it does not depend on async-std - the main dep is tokio. async-std was my attempt to try and cut down the binary size with a leaner async runtime (although it didn't make a big difference).

I also do not claim that zbus is bloated by design. The bloat is an unfortunate side effect of the non-blocking API using async internally.

And yes, I do agree with you that zbus is significantly faster. Unfortunately, the project I was trying to use it for back in 2023 had to be as small a binary as possible, and I noticed a huge delta between dbus-rs and zbus. I do not recall the exact numbers (that project is no longer being developed), but the binary in release mode was ~7M with zbus, and ~1.6M with dbus-rs. I would say that is non-trivial delta. I do recall having opt=z + LTO + strip enabled, and disabling features that I didn't need. There is a chance I was doing something wrong and causing more parts of zbus to be included than necessary.

[zeenix]

the binary in release mode was ~7M with zbus, and ~1.6M with dbus-rs. I would say that is non-trivial delta. I do recall having opt=z + LTO + strip enabled, and disabling features that I didn't need.

That's very interesting. That is indeed a huge difference and not something you can ignore (especially for constrained environments).

There is a chance I was doing something wrong and causing more parts of zbus to be included than necessary.

It's more likely because zbus 4 and (especially) 5 were not out yet. :) We've removed some unneeded features and made more features optional so that should help a lot already with the size. Most of the performance optimizations also came in 5.0 (released last Oct).

In any case, I do understand the need to keep the binary size small but I'm pretty sure we can bring it down to a level where it's not very relevant and well worth all the benefits zbus brings. We have a running issue for it.

Having said that, it's always good to have some alternatives and currently dbus-rs is the only one, so I would like this project to exist and continue. I must admit though that I wished this project hadn't take the dbus name on crates.io so people not using it just because it was the first hit there but rather some concrete reason like you had.