[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Duplicity-talk] Re: dbus patch

From: edgar . soldin
Subject: Re: [Duplicity-talk] Re: dbus patch
Date: Thu, 06 Nov 2008 15:57:41 +0100
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20080914 Thunderbird/ Mnenhy/

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]