Comment 19 for bug 479191

I don't understand the resistance to simply doing what many people are asking for. I provided a simple solution in comment 14. It certainly isn't the only way, but it would give us what we want and it isn't *at all* complicated. Or, I could also live with an approach that blacklisted certain times.

Otto's recommendations couldn't handle all the use cases, or they wouldn't handle them as well:

- First, he recommends running deja-dup --backup via cron. This is OK, I guess, but how are users who aren't watching this bug to know about the --backup switch. Usually, Gnome-ish apps don't have useful command line options, so it's not generally worthwhile to try to figure out how to run them that way. Some other drawbacks: If X doesn't happen to be running at the scheduled time, what happens?

- Examining the load and battery status would only be a partial solution. The thing is, it can't predict in advance which times would be bad to start the backup. So if my netbook with limited resources is idle while I'm teaching a class, deja-dup might decide that the conditions are right to run. But then, perhaps shortly thereafter I'll need the full resources of my machine and won't want to waste time pausing or stopping deja-dup. Handling this kind of situation is very simple if you can set a schedule, but very complex otherwise.

- Finally, Otto suggests choosing a backup time based on historical data. Again, this would work for some use cases, but not for others. In my case, my machine is connected to the same network most of the time. In addition, while I want my machine to be available during class, I don't use it in class every day. In many cases, I can't predict in advance when I'll need it. Furthermore, my class schedule changes every two months, which would make any historical data obsolete.

I'm not necessarily opposed to Otto's ideas. They could address some of the concerns. And indeed, it's best for deja-dup to have sensible defaults that most people won't need to change them. But as deja-dup is now part of Ubuntu's default install, it's important to support as many use cases as reasonably possible.

Nobody has critiqued my suggestion in comment 14. And I don't understand what the objections could be. The most commonly-raised objection is that of making the GUI more complicated. But there's plenty of room in the GUI for the options I suggested adding, and they're easy to understand, so there's really no significant added complexity there.

I'm urging the developers to be willing to consider adding more detailed scheduling. It's the only way to address all use cases presented.