Re: [Duplicity-talk] Re: dbus patch

[Michael Terry]

On Thu, Nov 6, 2008 at 6:15 AM,  <address@hidden> wrote:
> 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.

I did do 1 & 2 and left 3 for later.  See Déjà Dup 1.0.  Later has become now.

Déjà Dup currently has such "not satisfying, but hey the app works"
error reporting.  If duplicity reports an error exit status, we
display the contents of stderr.  Which has lots of crap in it besides
the actual error.  I'm *trying* to improve upon this.

As for who does backups by hand, that's what Déjà Dup currently
supports.  I have plans to support cron-like functionality, but first
I need these bits to land.

So, yes, duplicity is just user-friendly enough for the people on this
mailing list.  You can set it up well enough to put into cron then you
never have to deal with it again.  I'm trying to reach people that
don't have that technical savvy.

> And I expect it to develop some IPC interface later, but with a clear
> conscience that adding dependency is always restrictive in some way.

Why later?  What's wrong with now?

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

As I said above, Déjà Dup just displays stderr and the user can't do
anything about it.  With dbus and my patch, Déjà Dup can especially
handle some errors.  For example, on a command line error, Déjà Dup
would say "Sorry, mate, I fucked up.  Internal error."  Which isn't
very helpful, but more meaningful than "command line error".  On a
"source mismatch error", Déjà Dup can say "Hey, your sources don't
match.  [Cancel] [Continue anyway]" and recall duplicity with
--allow-source-mismatch if the user chooses.  But I can't do that at
all without IPC.  Right now if sources mismatch, the user is SOL.

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

If the user cancels, they have left overs.  And Déjà Dup (in bzr)
automatically calls "cleanup" if the user cancels, but we'd still end
up with cruft if for some reason Déjà Dup got killed or some error
occurred halfway through.

> we gave reasons, did you counter-argument these?

YES!

> http://lists.gnu.org/archive/html/duplicity-talk/2008-11/msg00016.html

DBus is optional, as I've said a million times.

> http://lists.gnu.org/archive/html/duplicity-talk/2008-11/msg00015.html
> http://lists.gnu.org/archive/html/duplicity-talk/2008-11/msg00014.html

http://lists.gnu.org/archive/html/duplicity-talk/2008-11/msg00017.html

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

But I want to make a Déjà Dup 2.0.

-mt