I'm working on a DBus service that needs to export objects on demand when requested by 3rd party applications. That part seems fairly strait-forward.
But I also need to "garbage collect" these objects when it has zero consumers. I could have API that requires the 3rd party applications to explicitly release the objects, but the downside is if the consumer application crashes without releases the references, unused objects would accumulate.
For what it's worth, I'm using DBus from Python via python3-dbus. So I have 2 questions I guess:
What sort of mechanisms does DBus provide for reference counting on exported objects, is there a way to know when zero processes are currently "observing" an object?
What is considered the best-practice for designing such a DBus API, and what do people think is a good example to follow? (The only thing like this I can think of is the Avahi Browser objects.)
My question will probably make more sense if I describe the exact problem: Dmedia is a specialized distributed file-system aimed at media files. Files are given a globally unique ID based on their content-hash. When an application needs to use a file (say for playback or display), it will use the Dmedia DBus API to resolve the file ID into a regular file path. For example, this ID:
Could for example resolve into the file:
But things are more complicated than that. The file might not be available locally, in which case Dmedia can download the file from one of the user's other devices or from the cloud. So we need signals for say download progress, and to signal what that regular file path is once a file is downloaded.
The resolution also might change over time when removable drives are connected or disconnected. A user might remove a drive, at which point the file isn't available locally and Dmedia would try to download it. Or the user might plug in an additional drive, and the resolution of a given file could change as Dmedia re-load-balances across the drives.
It seems that having a DBus object exported per current file-of-interest is a reasonable approach, but perhaps that's making things too complicated. I suppose it's the difference between needing more filtering and smarts on the consumer vs the service side. A flat collection of signals and methods on a single object would make things easier for the service, but put more burden on the consumer.
If we export a DBus object per-file-of-interest, I'm rather certain we need the garbage collection as a very large number of files can be of interest at some point during the DBus service lifecycle.
I'd much appreciate any advice on this!