Python-dbus needs some non-trivial examples
Written by
on
in
Snaking,
Tuxedo.
So I got tired of paying work this afternoon and decided I would work on getting a dbus service started for Listener. The idea here is that there will be a DBus service which does all the context management, microphone setup, playback, etc and client software (such as the main GUI and apps that want to allow voice coding without going through low-level-grotty simulated typing) can use to interact with it.
But how does one go about exposing objects on DBus in the DBus-ian way? It *seems* that object-paths should produce a REST-like hierarchy where each object I want to expose is presented at /com/vrplumber/listener/context/... but should that be done on-demand? If I have 20 contexts, should I expose them all at start-up, or should the user "request" them one at a time (get_context( key ) -> path?). Should I use a ObjectTree? How do I handle deletion/de-registration in such a way that clients are notified of the removed objects? I can hack these things in, but it would be nice to know the *right* way to do this kind of work. Should I expose functions that process directories (import this directory), or only those which process in-memory data-sets (add these words to the dictionary), can (python) DBus handle many MBs of data? What does a proper "real" DBus service look like?
So, anyone know of some good examples of python-dbus services exposing non-trivial services? Many objects, many methods, object life-cycle operations, many signals, yada, yada?
(BTW, my hacks are up on github if anyone cares to hit me with a clue-stick).
Pingbacks
Pingbacks are closed.
Comments
Comments are closed.