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!