Re: [Duplicity-talk] Re: dbus patch

[edgar . soldin]

> Shell-scriptabliity of dbus:  It's good.  With dbus-monitor and
> dbus-send, you can do everything you should need to.
>   

as ftplicity is plain bash (+ grep, awk), I'd rather take some piped 
info, in favour of less disk space and not having to have dbus, glib 
packages for ipc with duplicity.

> GLib dependency:  dbus requires glib.  But dbus (and thus glib) are
> only used if they are available.
>
> duplicity helper wrapper:  I'm not sure how this would work.  The
> wrapper would need some communication from duplicity that is
> machine-readable, so we'd just be adding an extra layer of complexity.
>  Did I not understand this?
>   

More a layer of interoperability. Worth it (size,dependency).

I like the idea of network backup monitoring. If we want this, we should 
think about it early.
A socket communication (allowed per commandline argument, secret for 
auth) comes to my mind. If a duplicity instance is already started it 
might prove difficult to communicate to it.

But this actually is very advanced and not part of the ftplicity use 
case. There _one_ backup/restore is started by hand/cron and output 
observed or sent per mail. Also I do not need to interrupt duplicity's 
job. On errors the user can resolve & duplicity gets started again.


regards ede