Consider replacing dbus crate with native rust implementation

[djmaze]

The dbus crate uses libdbus and thus makes it hard to create portable or statically compiled binaries. It would be very nice if the mpris crate could be used without C dependencies.

There are now several alternative crates for implementing dbus clients. For example, here is a list (including benchmarks). Maybe this crate could use one of those instead?

[Mange]

Very nice. I'm glad the ecosystem has expanded since I started working on this.

I agree. I might experiment a bit with this some time.

Does it make sense to have the backend pluggable using feature flags, or would it be better that we just pick one and use that one to not over-engineer anything?

[djmaze]

Cool! Personally, I don't see any advantages in having a pluggable backend. Sounds like much work for probably no gain in practice.

(Disclaimer, I am pretty new to Rust and not yet skilled in the language's best practices. So my opinion in this case is probably not of the highest value.)

[ssokolow]

Does it make sense to have the backend pluggable using feature flags, or would it be better that we just pick one and use that one to not over-engineer anything?

I've run into situations where I felt forced into choosing one implementation because the alternative was having two D-Bus implementations in the same binary. I could easily imagine myself running into a situation where I have no choice because two crates have decided they don't need feature flags and chose different implementations.

[peppidesu]

Hi, have you guys looked at zbus?

[Mange]

Yes, and there's also a draft PR #86.

Help is welcome. I don't personally use this library for anything at the moment, and I have an absolute mountain of other things to maintain that I've prioritized above it.

I'd love to have the time to get this going again, but I'm also realistic about it and don't expect anything for a long time on my end.