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

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.

It's more the status quo, I think everybody wants to have the userfriendliness improved.

I'm trying to reach people that
don't have that technical savvy.

exactly my point, simplify the use of duplicity for all parties involved.

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?

Nothing. I like the dbus-communicator concept, as it would be fully independent.

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

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

This leaves two alternatives, patience and coming together :) or parsing of the current output of duplicity, as an interim solution.

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.

If your gui or duplicity died without noticed by the user this would be the case too. Only that a unattentive user might trus that there i a backup, where there isn't.

we gave reasons, did you counter-argument these?



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




Ok, I think I understand now that dbus is not depending on glib? Is it? Which is my main concern.


reply via email to

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