[Top][All Lists]

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

Re: [Duplicity-talk] Re: dbus patch

From: Michael Terry
Subject: Re: [Duplicity-talk] Re: dbus patch
Date: Wed, 5 Nov 2008 20:14:17 -0500

On Tue, Nov 4, 2008 at 7:02 PM, Richard Scott <address@hidden> wrote:
> Any backup GUI that I've ever used has had these three basic features (aside 
> from
> scheduling/configuring backup jobs):
> 1) Start a backup job.
> 2) Stop a running backup job.
> 3) Display details about a running job.
> And from what I can tell, the answers to the above are:
> 1) execute duplicity.
> 2) kill duplicity (via pid).
> 3) parse the output from duplicity.
> All of these you can easily do in perl, python, php or bash etc so I'd expect 
> you can do this in
> any other language too?

The tricky one is number 3.  Parsing output meant for humans is
problematic; a frontend needs machine-parsable output.

Take for example the warning duplicity shows when it finds leftover
files that can be cleaned by "duplicity cleanup".  That's useful for a
frontend to know (so it can run the command for the user).  But trying
to watch for that message in text is crappy -- any change to the
wording or translation messes you up.

Hence dbus (or any IPC).  I'm a little surprised at all the resistance
to dbus.  Here's my pitch again:

Allowing frontends is a win for duplicity.  It grows the community,
grows the developer base (hi), and makes duplicity a more useful tool.
 As a frontend author, I need some sort of interprocess communication
(for the above machine-readable reasons).  I've made the case for dbus
as the best tool for this elsewhere.  These IPC bits can be completely
optional.  There are tangible wins, and no downsides.


reply via email to

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