lathiat
install <avahi-common/dbus.h>
Thank you for the PR
This header is useful when writing custom clients
Could you expand on why the avahi client isn't enough? I think the idea was to somewhat hide those things and expose them via avahi-client.
Could you expand on why the avahi client isn't enough? I think the idea was to somewhat hide those things and expose them via avahi-client.
Afaik libavahi-client uses a "blocking" i/o pattern when calling D-Bus methods. This pattern has already been questionized many years ago and the NetworkManager project has decided to remove this pattern from its client library.
The main reason for me writing an own client was that I try to avoid using blocking i/o in my application at all (in favor of requiring less threads). Although the blocking D-Bus calls of libavahi-client may return quite fast, using blocking i/o in a thread which also have to handle other (asynchronous) events is a little bit like peeing in the pool -- If you do this at too many occasions, it starts becoming a problem.
When performing asynchronous i/o instead, one typically needs to use am "i/o framework" (e.g. (Boost-)Asio or Glib). For my application I decided the use Glibmm/Giomm as there exists no suitable (license) D-Bus bindings for Asio and I am not clever enough to do the memory management right with Glib/Gio.
If the Avahi project is interested to add my bindings (C++/Giomm), I am willing to share them.
If the Avahi project is interested to add my bindings (C++/Giomm), I am willing to share them.
Generally I agree with the "No Client Library Wrapping D-Bus" part of https://networkmanager.dev/blog/notes-on-dbus
Many projects provide a client library that wraps the D-Bus API. Often such a library should not exist. D-Bus is already a reasonably convenient API to use directly, so all you need is a D-Bus client library and the D-Bus API specification of the service you’d like to use. No need for a wrapper around D-Bus.
so I'm not sure it should be added to the avahi project itself. That being said if it was published somewhere it would be possible to point people to those bindings. It would also be great in terms of figuring out what avahi can do to make it easier to consume its D-Bus API (which is what I think this PR is about).
Hi Evgeny,
... so I'm not sure it should be added to the avahi project itself. That being said if it was published somewhere it would be possible to point people to those bindings. It would also be great in terms of figuring out what avahi can do to make it easier to consume its D-Bus API (which is what I think this PR is about).
I have extracted the "Client library" from our project and put it here. I don't think that it is ready for general use, but should satisfy the "why do I need <avahi-common/dbus.h>" question.
Some notes:
- I didn't even try to implement all D-Bus calls. It is just what we currently use.
- The libsigc++ library has a limit on the number of parameters which can be passed to a slot. For simplicity I only pass the D-Bus values I actually require.
- The library is based on glibmm/giomm-2.66, as the current glibmm version requires libsigc++-3.x, which is LGPLv3 (not suitable for our project). Fortunately the OpenEmbedded project provides both versions.
Thank you for publishing it. I'll take a look. The Reconfirm example looks interesting.
should satisfy the "why do I need <avahi-common/dbus.h>" question
My thinking was that avahi could provide the D-Bus API specification or something like that to make it easier to consume its API regardless of the language. Currently it has to be somewhat reverse-engineered so to speak. I get why dbus.h makes it easier in this particular case but my concern that it's still kind of tightly coupled with the avahi libraries but I guess it's hard to decouple separate avahi clients from libavahi* anyway.
(Just to clarify I added the "needs-discussion" label because my opinion on what it should look like can be different from the opinion of the other maintainers so I'd wait for them to chime in as well).
My thinking was that avahi could provide the D-Bus API specification or something like that to make it easier to consume its API regardless of the language
Yes, yes! This is a common problem I see in many mature codebases - they do not install D-Bus XML descriptions and instead provide their own libs. It does make sense sometimes when the API library provides more high level interface than the D-Bus API, of course. But not installing the XML description at all is like not installing a header files for a library - it only makes sense for a really private API, not intended to be consumed outside of the project.
