sitter added a comment.
Yep, so, by default Windows 10 does no service publication. The only way to make a host discoverable is by manually starting a publication service (which the user could switch to autostart, so it starts automatically on subsequent boots). With that service Windows will advertise itself over ws-discovery. ws-discovery as far as I understand is only solving the finding device problem, not finding a service, nor name resolution (all of which dnssd can do). Iff we were to add ws-discovery support we'd still need to smb-poke found devices to actually determine if they are smb hosts and also obtain a name from smb_* or netbios or something (I am not sure about speed implications of either). As for actually supporting ws-discovery. I am really not fond of it and would possibly just ignore it given it doesn't work out of the box anyway. I've eventually gotten gsoap's wsd support <https://www.genivia.com/doc/wsdd/html/wsdd_0.html> to "work" in a sample program by randomly switching sockets *shrug*. soap->master = soap->socket; soap_wsdd_listen(soap, 5); But there's more! gsoap's facilities for changing network interfaces are compile-time ipv4-only or ipv6-only ifdef'd which makes for weird scenarios where you want to probe on ethernet and wifi but you can potentially not switch to one or the other because of how gsoap was built (it is as strange as it sounds). All in all I continue to feel meh about ws-discovery support and think lobbying for a dnssd based solution is way more useful in the long run. REPOSITORY R320 KIO Extras REVISION DETAIL https://phabricator.kde.org/D16299 To: sitter, #frameworks, #dolphin Cc: bcooksley, ngraham, kde-frameworks-devel, kfm-devel, sourabhboss, feverfew, michaelh, spoorun, navarromorales, firef, andrebarros, bruns, emmanuelp
