Re: [Duplicity-talk] Re: dbus patch

[Michael Terry]

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.

-mt