Future plans and forcing local backups

[Michael Terry <mike mterry name>]

Heyo!  So 20.0 is out.  There is one bad bug [1], but I'm hopefully
getting that fixed this week.

My plans for 22.0 (GNOME 3.4) are small.  I'd like to fix small issues
and focus on duplicity more this cycle.  This is partly motivated by
being included in Ubuntu by default and wanting to be yet more robust
to reduce incoming bugs to as small a flow as possible.  And partly
motivated by the next Ubuntu version being an LTS that will force me
(as a Canonical Desktop Team member) to support it for the next five
years.

But, I do have some ideas for future versions (maybe 24.0/GNOME 3.6).
I'm at UDS now and got a chance to talk to Ubuntu designers here.  One
thing that came up is the need to reduce latency for some of my
desired feature/workflows.

One thing I'd like is to make it easier for users to understand which
version to pick when reverting to a previous version.  I think the
best way is a "slider preview" when you're restoring a file.  You can
drag a slider to see different previews of the file back through time
to pick the one you want.  That would need to be fast.  Way faster
than we can do today.

Also imagine a backup browser, which has been a long desire.  It's a
much better way to find files you want to restore than the current
ways.  But it's a hard problem and would be super slow with the
current setup.

And it would make the current pain point of large remote backups can
take over a day much less painful.

I'm not excited about changing the backup format (which would be a
long long project), but an easy win would be to backup locally and
then separately sync that up to a remote destination.  Duplicity
maintainers actually recommend that work flow.

This would probably mean keeping all your backups online and your most
recent backup chains locally (on the assumption that 90% of users
would want the most recent couple versions).

This would mean adding more logic at the deja-dup level to talk to the
various backups (we know GIO easily enough but the cloud destinations
are trickier).

Unfortunately, this would mean taking up large, large amounts of space
on disk too.  I suspect from a user experience point of view (much
faster backups, more understandable restore workflow), it's worth it.
But I'm not sure how to best explain to the user that even though they
chose to backup to an SSH server, we're still going to consume huge
amounts of local disk.

Thoughts?

[1] https://bugs.launchpad.net/deja-dup/+bug/877631

-mt