Future Plans Brain Dump

[Michael Terry <mike mterry name>]

Hello!  Version 22.0 is almost out the door.  The 22 cycle was light.  Just some minor maintenance.  However, I have big multi-cycle plans!

At the start of the 22 cycle, I had several discussions with designers about what a good backup browser experience would look like.  (The ability to visually examine your backup is one of the biggest missing features in Deja Dup.)

And a lot of it came back to the need for responsiveness.  To be able to flick between versions of a file.  To be able to preview an older version quickly.  To be able to show when a certain file changed in history.  A lot of this is difficult due to the latency inherent in the sort of remote backup locations that Deja Dup encourages.  Especially when you add in the latency of unbundling duplicity's backup format.

Change 1: Forced Local Backup

So that got me thinking about requiring a local backup.  Either in the user's ~/.cache or on an external drive.  Time Machine does this, to seemingly great success.  So I don't think this is an especially onerous requirement.

This would reduce the greatest source of latency.

Technical feasibility: Trivial.  Duplicity supports this already.  It would actually solve some issues around using duplicity under sudo while talking to remote locations.

Change 2: Optional Remote Mirroring

Optional for the user, that is; I would require this functionality to be implemented.  We can mirror the files in the user's local backup to a remote location in the background.

Technical feasibility: Sorta difficult, but solvable.  Would require duplicating logic for the special cloud backends (S3, Rackspace, U1) to Deja Dup itself.  And keeping two sets of files in sync is famously more difficult than one thinks.  Thankfully, it's mostly a write-only situation.

Side Effect 1: Lowers Dependency on Duplicity

If both changes above are made, we'd only need duplicity for local backups.  Which means its largest advantage over other backup tools (a file format that makes it easy to support cloud locations) is moot.  So we could potentially investigate supporting other tools.  This is very much not something I'm eager to do, as that would just double Deja Dup's support headache, but it'd suddenly be on the table at least.

Change 3: Actually Implement Browser

After performance becomes good enough, we could offer a backup browser that wouldn't make users poke their own eyes out.  Would need some good design thinking here too.  This isn't fleshed out yet, and would take time.

Technical feasibility: Hard work, both design wise and UI wise.

Change 4: Split Backend/Frontend More Fully

Deja Dup has an internal library that it shares between its various UI programs.  But I'd like to make some form of that available for 3rd parties to use.  Either a library, DBus service, gvfs backend(?!) or some such.

Some use cases here would be (A) an app wants to let a user roll back to a previous version of a document.  Or (more likely) (B) someone wants to create a UI that serves a different market than the simple use cases Deja Dup caters to.  (i.e. an Advanced Deja Dup app)

Technical feasibility: Very difficult to do right.  And this is less important than the above changes.  But thought I'd mention it.



A to B

So how do we do any of the above?  I'm going to focus more on Change 1 & 2, as those are the low hanging fruit and the more likely to introduce new bugs (so I'd like to make them happen sooner rather than later).  I think the changes need to come together or not at all.  It may take multiple cycles to land them, depending on how much time I get to work on it.

All the work is in the remote mirroring.  Part of that would also be conversion of old remote-only locations to dual locations.

Distinct bits of work:
 * Refactor backend support (Make each backend a dbus service?  Can just directly steal Duplicity's python backends if we do that, since they are GPL2+)
 * Add mirroring support to deja-dup-monitor (it can happen in the background, not something user needs to wait on)
 * What happens when an error occurs?
 * What happens when a file differs between remote and local?
 * Conversion of old remote-only location
 * Preference UI changes
 * Maybe more...


Anyway, this was just a brain dump to get feedback and perhaps inspire people if they were thinking there wasn't anything to do.  :)

I don't know if we can get 1&2 done for cycle 24 or not, but it would be a neat goal to try.

-mt