The openSUSE -- probably other Linux CI builders, too -- image doesn't have avahi properly installed, so building kdnssd finds no backend to use. See https://build.kde.org/job/Frameworks%20kdnssd%20kf5-qt5%20SUSEQt5.10/lastSuccessfulBuild/console for a full log. Windows doesn't have it, either.
See https://phabricator.kde.org/D13328 where it becomes mandatory to have a backend -- although we could discuss whether a backend should be required.
It doesn't look like Avahi is available on Windows at the moment, at least not in Craft so this might pose an issue there.
I'm guessing KDNSSD should probably use native Windows code here, unless libavahi works on Windows?
Thoughts on Nicolas' suggestion Hannah?
I'm not sure if we'd actually be able to use Apple's Bonjour implementation on Windows though as I don't think their libraries and Avahi are compatible.
I suspected as much. Thoughts on what we should do in regards to a KDNSSD backend on Windows?
(Ideally I guess we'd work the standard Network view Windows provides, not sure how possible that is though)
I thought KDNSSD already had backends for both Bonjour and Avahi.
The problem with Avahi on Windows, even if it was supported, is that you can only have one mDNS daemon running at a time on a computer. If the user already installed iTunes or iCloud tools, they already have Apple's Bonjour / mDNSResponder installed and running. Running the Avahi daemon at the same time won't work.
On macOS, Bonjour is always running (and it would break system to disable it), so again you can't use Avahi there.
We don't need to ship the daemon, we just need to talk to a running one. In any event it would appear that KDNSSD is designed to use D-Bus to talk to Avahi, so it's unlikely that Apple's Bonjour implementation would be usable by it in any event.
So the correct fix in the interim I would say would be to continue to use the dummy backend on these platforms until such time that someone who needs it to work gets it to talk to Bonjour (on macOS) and the Windows Network Discovery system (on Windows).
@adridg Thoughts on the best way forward here?
Just for those interested, I'll note that using DNSSD on macOS might be harder than we initially thought as it fails to build there, at least on the Binary Factory.
See https://binary-factory.kde.org/job/Dolphin_Release_macos/121/console
Some FTRs:
kdnssd abstracts the concept of a dnssd library. The public API is not in any form designed around dbus and should map nicely to apple's API from what I see https://developer.apple.com/documentation/dnssd/dns_service_discovery_c
Windows has official dnssd api https://docs.microsoft.com/en-us/uwp/api/Windows.Networking.ServiceDiscovery.Dnssd which kdnsssd would/should use. This is however limited to Windows 10, so there may be an argument for also using bonjour on windows to support older versions [nb: kdnssd backends are actual implementations, not plugins, so as of right now we couldn't actually have both native and bonjour support at the same time]
Also please note that ws-discovery is an entirely different protocol unrelated to dnssd. It's only useful to discover devices (as in: "Hello, I exist and I am a Computer style device"), which isn't nearly everything dnssd does. It's unsuitable to back kdnssd IMO.
Thanks Harald.
In regards to MacOS I believe we already use that API - or at least I have seen build failures due to it.