Help designing DBus API

[Mikkel Kamstrup Erlandsen]

On 07/13/2012 12:53 PM, Arvin Schnell wrote:
>
> Hi,
>
> 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.

Cheers,
Mikkel