Re: [Duplicity-talk] Re: dbus patch

[edgar . soldin]

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

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?
http://lists.gnu.org/archive/html/duplicity-talk/2008-11/msg00016.html
http://lists.gnu.org/archive/html/duplicity-talk/2008-11/msg00015.html
http://lists.gnu.org/archive/html/duplicity-talk/2008-11/msg00014.html

> 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