[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 12:15:10 +0100
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20080914 Thunderbird/ Mnenhy/

Any backup GUI that I've ever used has had these three basic features (aside 
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.

Why not start with 1 & 2 then and leave 3 for later? Error handling as well as information about current state are currently more meant for debugging and developers (verbosity switch, very similar to rsync, btw how do rsync guis handle that?). Not satisfying, but hey the app works, and once it's working (mostly from cron), who needs current state info, you get a cute summary in the end? Why doing backup by hand (see Kens mail)? All I want to say by that is: in terms of usability regarding errors or user interaction (e.g. run duplicity without arguments) duplicity has still some long way to go. And I expect it to develop some IPC interface later, but with a clear conscience that adding dependency is always restrictive in some way.

Speaking of usability: More important then progress metering or details about, what is duplicity doing right now, might be guiding users through error scenarios. I didn't have a look at your frontend by now, but already know from ftplicity development that there are some hurdles to be taken until everything works flawlessly. What does Deja Dup in case of errors, how does it support the user to solve these?

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).

actually if there are leftovers, this is asign that something broke in the middle. So the user should be bothered at least with a warning.

But trying
to watch for that message in text is crappy -- any change to the
wording or translation messes you up.
true .. this should be translated into an exit code 'success but left overs'. Also it should be part of the above mentioned IPC development.

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

we gave reasons, did you counter-argument these?

Allowing frontends is a win for duplicity.  It grows the community,
grows the developer base (hi), and makes duplicity a more useful tool.

duplicity allows already as your Deja Dup 1.0 clearly proves, there's just no majority for dbus integration now

 As a frontend author, I need some sort of interprocess communication
(for the above machine-readable reasons).

again there are other ways to communicate, and machine readablility is still to develop as such

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.

what does duplicity with your patch do if there is no dbus in any way around? No lib, no dev package, no nothing.
Does duplicity work as it does now, including setup routine?

regards ede

reply via email to

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