D-Bus API for clients?

[hadess]

A D-Bus interface would be particularly useful for applications to be able to do service discovery using wsdd. gvfs, the user-space filesystem used by GNOME and others, could use it to find Windows 10 SMB machines on the local network (see https://gitlab.gnome.org/GNOME/gvfs/-/issues/506)

[christgau]

Sounds interesting. At a first glance I shared oholy's thoughts: a [C] library would be a better idea, but repeating all the stuff (in C/C++) that is already in wsdd appears to be cumbersome. Thus, using wsdd appears to make sense. But it would require users/distros to install wsdd and run it in discovery mode which should be used as single operation mode by default IMO (as long as nothing else is intended). However, this kind of problem might be out my scope 😉 but I assume it has to be considered. And just for the records, I'd also like to add that the discovery mode (searching for other WSD machines) has not been extensively tested. It was implemented as a diagnostic/quick look feature for the local network.

Anyways. I like that idea but I have currently no experience in implementing such an API for D-Bus. I've found a tutorial for Python and D-Bus but it appears to be dated (Phyton 2.4). Existing libraries have a strong dependency to Glib which seems to make it hard to other "MainLoop" concepts, or depend on twisted, or have limitations whose impact I am unable to judge. I do not want to refactor the whole code to make it fit into, e.g., Glib's main loop concept and I do not want to introduce a dependency such that the code becomes (much) harder to use on different architectures. IMO, the ideal solution would be connect to dbus, get a file descriptor for that, put that descriptor into a "selector", and handle the traffic on that descriptor accordingly. However, from my quick and sloppy look into the APIs they do not seem to support such an approach. If I'm wrong, just let me know.

Putting that technical issue aside: What would the API look like from your side? My first idea: Having an object under /tld/domain/wsdd/KnownHosts with methods like those currently supported by the primitive socket-based API: scan, list and clear of which the second returns the list of known hosts in a format to be discussed....

[hadess]

I haven't looked into a possible implementation, but I'm pretty sure we can find a way to integrate a D-Bus server without overhauling the main loop you already have. That code would actually need some changes, if we're going to have to wait for events on 2 fds rather than just the one, right?

I might look at this when I'm in between projects, if nobody beats me to it. Thanks!

[christgau]

I'm pretty sure we can find a way to integrate a D-Bus server without overhauling the main loop you already have.

That would be great.

That code would actually need some changes, if we're going to have to wait for events on 2 fds rather than just the one, right?

Not really:

wsdd/src/wsdd.py

Lines 1643 to 1646 in 1d3c5f7

	while True:
	try:
	timeout = send_outstanding_messages()
	events = s.select(timeout)

wsdd/src/wsdd.py

Lines 1263 to 1272 in 1d3c5f7

	def __init__(self, selector):
	super().__init__(selector)
	self.intf_blacklist = []
	# Create routing socket to get notified about future changes.
	# Do this before fetching the current routing information to avoid
	# race condition.
	self.socket = socket.socket(socket.AF_ROUTE, socket.SOCK_RAW,
	socket.AF_UNSPEC)
	self.selector.register(self.socket, selectors.EVENT_READ, self)

The code is designed to allow multiple FDs to register at the selector. Thus, something like this would work

class DBusHandler(object):
    def __init__(self, selector):
         import some_neat_dbus_library as dbus
         self.socket = dbus.createConnection(...)
         selector.register(self.socket, selectors.EVENT_READ, self);

    def handle_request(self):
         """ handle dbus specific stuff """"

# in main 
if args.dbus:
    DBusHandler(s)

I might look at this when I'm in between projects, if nobody beats me to it.

Great. Feel free to create a fork+branch/PR/whatever so we can share work force resources 😉

Thanks!

You're welcome!

[christgau]

@hadess Is this still needed? I see that @ondrejholy did some awesome work of integrating the discovery mode into GVFS. This is not exactly the same thing that was requested here, but I guess it originates from the same GVFS issue, which has been resolved in the meantime...

[ondrejholy]

It would definitely be nice to have D-Bus API and use that in gvfs instead of the socket-based API which is a bit cumbersome to use. However, my python knowledge is poor, so I used the already existing socket API for now instead of implementing a new D-Bus API...