Recommend zbus and discourage gio for D-Bus

[zeenix]

It has happened a few times already that people come to me (or zbus matrix channel) and say that what a great pleasure it was for them to write their D-Bus code using zbus after suffering through a lot of pain while trying to do the same with gio-rs. While I'm sure gio-rs' can be improved, I doubt it can get on par with zbus w/o extensive changes (if it's possible even).

So I recommend we help people avoid the pain and get them straight to zbus through documentation. I can try to cook a PR for this but I'll need pointers on where to add such docs.

[sdroege]

Getting convenience close to zbus should be possible but it would require to put a lot of effort into that, and basically replicate (parts of) zbus. Neither of us two is going to do that, and the only reason why I merged the current gdbus bindings is because it was apparently useful for some people :)

[bilelmoussaoui]

The gdbus API has still use cases when interacting with gobject based libraries that wraps a dbus API. We can't make those libraries use zbus from rust without rewriting them from scratch. So I don't see anything actionable here personally.

[zeenix]

The gdbus API has still use cases when interacting with gobject based libraries that wraps a dbus API. We can't make those libraries use zbus from rust without rewriting them from scratch.

Sure. That's why the API should still exist and be supported.

So I don't see anything actionable here personally.

Not everyone is using gdbus binding because of the integration. Many people (like the someone on zbus matrix channel today) use it because they're already using gio-rs in their code anyway so it's natural to reuse gio-rs for dbus as well. We need docs to nudge these folks to use zbus instead.

[bilelmoussaoui]

Patches are welcome.

[swsnr]

I can across this ticket while writing a search provider for my application. I've written a search provider with zbus before, and now wrote one with dbus, and it wasn't a lot worse than zbus.

Sure, unlike gdbus doesn't deserialize arguments automatically, but serialization codes mostly comes for free since basic types already have variant conversions, and variant conversions for structs can be derived.

Having to provide the XML interface description and having to copy the XML around was a bit of a nuisance, as is having to dispatch method calls manually based on the method name. The biggest inconvenience is probably having to chain the invocation object through, because there's no async support in the gdbus API in Rust.

All this is nicer in zbus, but for my part not so nice as to warrant buying into the rather heavy dependency chain of zbus which would have about doubled the size of cargo tree for my application, and probably compilation times as well.

Not asking for anything; just wanted to offer a different perspective :slightly_smiling_face:

[zeenix]

I can across this ticket while writing a search provider for my application. I've written a search provider with zbus before, and now wrote one with dbus, and it wasn't a lot worse than zbus.

You're free to choose what works best for you but we're not even talking about dbus-rs here. Most folks move from dbus-rs to zbus and report that their life is much easier now (especially people needing to cross-compile) and if you look at the number of downloads on crates.io alone, you'll find that zbus has double the numbers, despite dbus-rs having many years of headstart.

Moreover, dbus-rs hasn't seen a release for almost 2 years.

So while I'm super biased here (as the zbus author), I still think it's best to recommend zbus still.

All this is nicer in zbus, but for my part not so nice as to warrant buying into the rather heavy dependency chain of zbus

This is as subjective as it gets. :) How many are too many? For some, 10 is already a lot. Does it really matter if even the cold build takes less than a minute on a not-so-high end machine? For devs, the hot build matters the most anyway.

which would have about doubled the size of cargo tree for my application,

Not sure why I've to keep reminding people of the simple fact that number of dependencies have very little affect on binary size, if you build the binary with LTO in release mode (which IMO you should in most cases). Yes, zbus currently has a not-so-ideal binary size but it's mostly a very solvable issue and I've ideas I'm planning to work on to reduce it significantly.

and probably compilation times as well.

I'd suggest checking the actual difference instead of making a guess. :)

We should also consider the fact that the build time of the underlying C library get completely ignored here, because it's assumed to be used from the platform. It's typically readily available on most Linux distros so I see why but you also have zbus packaged for most distros these days and you can rely on that, if reducing cold compilation is important in your case.

[zeenix]

Oh and while updating these benchmarks, I found out that the (heavily optimised) zbus 5, is extremely faster than dbus-rs. We're talking 250 vs. 7 µs here. I'd think that's a lot more important than a few hundred KBs of binary size bloat (that will hopefully be reduced in the near future as well).

[sdroege]

@zeenix That comment was about gdbus, not dbus-rs

[zeenix]

@zeenix That comment was about gdbus, not dbus-rs

@swsnr wrote dbus so I got confused. Sorry. :see_no_evil:

[swsnr]

@zeenix Oh sorry, pardon my typo :pensive: I'm sorry for the confusion :see_no_evil:

[zeenix]

@zeenix Oh sorry, pardon my typo :pensive: I'm sorry for the confusion :see_no_evil:

No worries. A lot of what I wrote, apply to gdbus as well. Especially the performance bit (I was just reminded by a glib developer how it's a performance nightmare and needs a complete redesign).

[swsnr]

I'm sure, and I have used zbus in other projects, but for my dead simple tiny desktop app it's really a bit too heavy. A small dependency footprint and the ability to export objects on the app's actual bus name is more important to me in this case than good design and excellent performance. :slightly_smiling_face:

In other words, instead of shoving the last few ms off the occasional DBus call I prefer not to drown in dependabot pull requests and I appreciate that my app ID is also my bus name for all my busctl commands which makes them much easier to remember. :innocent:

If gdbus had been all that terrible I'd have used zbus nonetheless, but I found that it's not so bad, usability-wise, and that's just the (entirely subjective and absolutely unscientific :sweat_smile: ) perspective I wanted to offer :slightly_smiling_face:

[zeenix]

but for my dead simple tiny desktop app it's really a bit too heavy. A small dependency footprint and the ability to export objects on the app's actual bus name is more important to me in this case than good design and excellent performance. 🙂

Sure and as I already mentioned earlier here, there are reasons why people would use gdbus but I don't think that should be the criteria for the recommendation here.

[bilelmoussaoui]

As much as I like zbus, I think if we go this path we would have to also recommend things like https://github.com/felinira/gvdb-rs which is an alternative to the gvdb format / possibly even the gresource API in glib.

So this is going to be just "don't use glib" and use rust alternatives. I don't think we should get into that business. The crates provides the bindings, people should know what they are using and whether that fits their needs/use cases or not.

Let us close this.

[zeenix]

As much as I like zbus, I think if we go this path we would have to also recommend things like https://github.com/felinira/gvdb-rs which is an alternative to the gvdb format / possibly even the gresource API in glib.

How often do people come on the Matrix channel saying that they could have been saved a lot of pain if they knew about gvdb-rs?

If you read the description of this issue, you'll notice that the only reason I created this issue was to save people time and energy.

[bilelmoussaoui]

Seriously, no one has asked about gdbus in the Rust matrix channel in a very long time now. I spent a tremendous amount of effort writing wrappers around zbus for common DBus APIs people need so I am not really pushing against zbus but I don't think it is something the bindings should deal with, if you want to add some note to the GIO readme to recommend using zbus for DBus usage, feel free to send a patch.

[sdroege]

If you do that, make sure to also mention the downsides for any GTK application though

[zeenix]

One last short comment for the record before I unsubscribe from this:

if you want to add some note to the GIO readme to recommend using zbus for DBus usage, feel free to send a patch.

The gio API is great for C. It makes no sense for a C library docs to recommend using a Rust library instead. gtk-rs would be the right place for this, since it's what turns gio into a Rust library.

Even if I provide this patch to gio, I'm 100% sure it will be shot down or ignored forever, so no, I'm not going to waste my time.

[bilelmoussaoui]

You already lost a ton of time commenting here instead of doing something useful with your time.

[bilelmoussaoui]

And no, I was talking about readme of the GIO bindings, not the C library.