Re: [Deja-dup-hackers] DejaDup



Hi, Jeremy!  I'm moving this thread onto the list, like we said.

On Mon, Dec 15, 2008 at 6:20 PM, Jeremy Katz <katzj redhat com> wrote:
> I looked at current bzr as of the beginning of last week.  And then I
> got busy with Real Work (tm) and haven't had a chance to get back to it.
> Now that my classes are over for the semester, I'm going to have some
> more time and I'm also hoping to carve out some work time to spend on it
> too

Cool.  I've been trying to list bugs/features as they are
suggested/found.  So there's plenty of bite-size work to be had.  I'd
suggest adding ssh support (bug #307630), since it sounds like you'd
need it before Deja Dup is useful to you anyway (and I hear that a lot
among developers that already have their own backup solution).  Adding
support would largely be copying code from the S3 backend, so it might
be a kind intro to Vala.


>> Deja Dup:
>> * Add session inhibit dbus support for while we're backing up
>
> Should be straight-forward enough.  Although ultimately there's also a
> need to be robust in the case of a failure.  Networks and power can go
> away and corrupting backups in those cases would suck

Yeah.  Resumability in duplicity is something that I think Deja Dup
absolutely needs in order to be a robust user app.  With resumability,
backups are no longer a _big deal_.  We don't have to optimize the
user experience for size (bug #307193) or inhibit the session (bug
#284522).  Backups just become a background detail. We could probably
change the default from a week to a day and act a little more like
Time Machine.


>> * Come up with a compelling 'restore' story (current experience is poor)
>
> I think that ultimately, restoring is something that wants to integrate
> well with some of the work that Federico and others are doing with sort
> of a timeline view of your work.  Integrating in nautilus definitely
> feels like the path that makes usability sense to me, but it's certainly
> something that mockups and testing will help with

That would be neat.  I think that's orthogonal to the 'push a button,
get a restore' part of the main UI, but definitely a good idea.  We
could even add a right-click option in Nautilus to restore individual
files.  Restoring to a version of a file that you just messed
up/deleted seems to be a highly desired feature, and having it right
there in the file manager does make sense.


>> * Fix passwords-in-memory to be more secure
>
> What's the insecurity now?  Also, password wise it probably makes sense
> to use gnome-keyring

We do use gnome-keyring.  But we get the passwords from it back, and
from that point on, we might leak it.  In particular, we set the
password as part of the environment of the child duplicity process (no
other way to specify it).  Not a problem for Linux, but other Unices
leak environments.


>> * Port to newest vala

This is done by the way, up to and requiring 0.5.2.

>> * Use packagekit to install missing run-time dependencies (duplicity,
>> python-boto, others?)
>
> Why do this as a runtime thing instead of just having them required?

Sure, packagers like Debian and Red Hat will make this not-an-issue,
but for that person that downloads the source tarball, it would be
neat to have a better experience.  Not super-high priority.


Thanks for your interest!  I hope you have time to work on Deja Dup.  :)
-mt




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]