Help designing DBus API
Mikkel Kamstrup Erlandsen
mikkel.kamstrup at canonical.com
Fri Jul 13 04:07:32 PDT 2012
On 07/13/2012 12:53 PM, Arvin Schnell wrote:
> I could use some advice designing a DBus API for snapper, a tool
> to manage filesystem snapshots (e.g. btrfs). One method call in
> the snapper library makes me wonder what an appropriate DBus API
> should look like.
> The method call can take very long, e.g. several minutes. It has
> callbacks to 1. give feedback (which file is currently restored)
> and 2. report errors (some file could not be restored). In the
> future the error callback might also give to user the choice to
> continue or abort.
> AFAIS DBus does not offer callbacks. It offers signals but those
> are sent to every client and naturally cannot return anything.
> What is the best way to call this method via DBus?
In Zeitgeist we use a kind of "monitor pattern" that could be well
suited for this.
The signature would be like:
com.example.Service.DoLongCall (in o monitor)
DoLongCall takes a path to an object *on the caller side* that
implements some monitor interface, eg:
com.example.Monitor.Ping (in f progress, in s message)
com.example.Monitor.End (in i status, in s message)
The service then figure out the unique name of the caller from the
message and records that together with the caller's object path. It then
sends status updates to the caller's monitor that way.
It does require that both ends monitor each other's connections to make
sure they can clean up on errors etc. But it works very well in practice.
More information about the dbus