sitter added a comment.
This diff does somewhat depend on D16298 <https://phabricator.kde.org/D16298> as currently KDNSSD can easily lock indefinitely on resolving services. We could kinda bypass this with a timeout on service resolution, that would however have the disadvantage of either having to repeat the resolution or not showing the device. Both of which suck a bit. My plan is to simply have the fallback only run with KDNSSD 5.52 (assuming that gets the fix landed). Besides that this is working nicely for me. I would love to have a way to actually get the workgroup from a share, but from some research that seems simply unobtainable (via smbclient anyway) unless SMB1 is used (as in: if you use the smbclient CLI it would transparently drop down to SMB1 for the workgroup query but even that doesn't work if the minimum version is set >=SMB2). So we could drop to SMB1, but honestly I fail to appreciate the use in that in particular since the maintainer of SMB within Microsoft is very insistent on people not using a 30 year old insecure protocol anymore (rightfully, I should add ;)) In D16299#345363 <https://phabricator.kde.org/D16299#345363>, @ngraham wrote: > Wow, awesome work. What more is needed to support Windows? Support for the `WS-Discovery` protocol? Yes. I am not sure we have a production quality lib for that anywhere though. I haven't had much of a look since it's tricky to try in my network. There is however a good chance windows 10 already does, or possibly will at some point in the future, embrace dnssd like the rest of the world https://channel9.msdn.com/Events/Build/2015/3-79 REPOSITORY R320 KIO Extras REVISION DETAIL https://phabricator.kde.org/D16299 To: sitter, #frameworks, #dolphin Cc: ngraham, kde-frameworks-devel, kfm-devel, feverfew, michaelh, spoorun, navarromorales, firef, andrebarros, bruns, emmanuelp
