make use of other d-bus library

[gbaranski]

maybe zbus would be good? It's async, doesn't depend on any C library, so can be cross-compiled easily.

[qwandor]

It didn't exist when I was writing this, but yes, now that version 2 of zbus is released it could be an option, and being pure Rust would be nice. I don't have the time to rewrite everything and test it, but if you'd like to have a go you're welcome to. It will need to be tested fairly well before we can release though, because there are a bunch of different people using this library for a range of devices, either directly or via btleplug.

[zeenix]

zbus author here. 👋

It didn't exist when I was writing this, but yes, now that version 2 of zbus is released it could be an option,

Just fyi, it was released beginning of this year and now we actually have 3.0 (which is almost the same API, except it provides much tighter tokio integration, when tokio feature is enabled).

t will need to be tested fairly well before we can release though, because there are a bunch of different people using this library for a range of devices, either directly or via btleplug.

Based on feedback and download statistics (we recently surpassed dbus-rs downloads on crates.io despite the multi-year headstart they had), I think you can assume it's fairly well-tested already. However, I'm biased of course so don't take my word for it. :)

[zeenix]

It didn't exist when I was writing this, but yes, now that version 2 of zbus is released it could be an option,

Just fyi, it was released beginning of this year

Oops, sorry. I misread that as "once zbus 2.0 is released".

[qwandor]

I mean that a rewrite of bluez-async to use zbus would need to be tested a fair bit before release. Even if zbus has no bugs, it's still different to dbus-rs, and adapting to those differences might introduce bugs in bluez-async. If someone wants to take on the rewrite and testing they are welcome to! I'm supportive in principle, I just don't have much time to dedicate to it.