Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add D-Bus signal APIs #11

Open
dlech opened this issue Sep 9, 2022 · 3 comments
Open

Add D-Bus signal APIs #11

dlech opened this issue Sep 9, 2022 · 3 comments
Labels
enhancement New feature or request

Comments

@dlech
Copy link
Collaborator

dlech commented Sep 9, 2022

In Bleak, we have some code that is a nice wrapper around org.freedesktop.DBus.AddMatch and org.freedesktop.DBus.RemoveMatch that would be nice to include in this package to make subscribing to signals in the low-level API easier.

https://github.com/hbldh/bleak/blob/develop/bleak/backends/bluezdbus/signals.py

@dlech dlech added the enhancement New feature or request label Sep 9, 2022
@mdegat01
Copy link
Collaborator

mdegat01 commented Sep 14, 2022

The proxy interfaces of the library already allow you to attach a callback to a signal and then remove that listener later using on_<signal> and off_<signal> as described here: https://python-dbus-next.readthedocs.io/en/latest/high-level-client/aio-proxy-interface.html . Seems like that's what you're describing and showing? Or is there an issue with that feature I'm not aware of?

@dlech
Copy link
Collaborator Author

dlech commented Sep 14, 2022

We are using the low-level APIs, not the high-level APIs. And even if we were using proxies, they suffer from a race condition where you can't subscribe to the signals until after the object is created and so you end up having to call "GetManagedObjects" twice.

Additional motivation: altdesktop/python-dbus-next#53

@mdegat01
Copy link
Collaborator

mdegat01 commented Sep 14, 2022

Interesting, didn't know that. In supervisor we currently use the low-level APIs for signal listening as well but for a different reason. Currently in supervisor the only time we listen for signals is for confirmation of an asynchronous action. Like when changing the active connection in network manager we then listen for the StateChanged signal to confirm it worked. Similar when installing a rauc bundle file it fires the Installer.Completed signal when done.

So we can't use the on_<signal> functions there because we aren't continuously listening for a signal and acting on each one. Instead we specifically listen for a signal one time after we take an action and wait for it, using it to craft the response to the client that initiated it. This for reference is a capability I was also considering moving to the library in the future, basically a with_<signal> method that supports this:

async with proxy.with_signal() as signal:
  proxy.call_start_something_async()
  resp = await signal.wait_for_signal()

I was also planning to enhance supervisor with the ability to continuously listen for PropertiesChanged events on the objects it cares about. I had been planning to use the high-level client for this but I guess I'll have to review this now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants