Hi Shinnok, On 23 June 2015 at 00:56, Shinnok <[email protected]> wrote: > Hi list, > > So what I propose is: > > 1. Adding an extra Job specific option, a checkbox, "Include in automatic > backups"; > 2. Add --cron option to the application. Upon firing up with that parameter, > Tarsnap will execute headless and initiate job backup on all jobs that have > the previous option checked, in a sequential manner. > 3. The user proceeds to create a scheduled invocation of "tarsnap-gui --cron" > with his scheduler(system or something else) of choice and at his own > preference of interval and cadence. > > I'd be the first user of that. I like the simplicity of it and the fact that > I don't need an extra daemon to "watch" over stuff for me. > > Specific questions: > > 1. Does this sound useful for anyone else besides me?
Yes, I like the idea! > 2. Should I name the parameter --cron differently, maybe something more > inviting like --run-jobs or --scheduler? "Backup schedule", "scheduled backups" "schedule this backup" ? > 3. Regarding feedback from the automatic backups(failure, insights), for now > the application will print everything to stdout and the user is free to > redirect it to his log file of choice. But for the future and given that > Tarsnap is a sexy desktop application I might add: > a) System tray/menubar popup notifications (completion, failure, extra > info) > b) The ability to open the application to view more details from the said > notifications > c) Persistent Backup log (this is part of another Idea feature) > I'd like all three but option c is a really good idea. > On a different note, > > I have another change that I want to make but first I'd like to probe it > against this list: > > I'd like to change the default directory for newly generated keys(via the > Setup Wizard for now) from the system specific APPDATA ones, which currently > are: > 1. ~/.local/share/ on Linux/BSD > 2. ~/Library/Application Support/ on OS X > > To just ~/Documents. The reasoning behind it is that we shouldn't hide the > keys in such obscure places since they are not transient nor expendable, > whereas the application's data is. We also invite the user to keep the key > safe(on wizard complete), but then provide a path that he's most likely to > ignore in first instance and then completely forget about it. Another aspect > to consider is that a user should be a bit more careful with stuff residing > Documents, rather than some obscure hidden system paths. Think backups, > system restore or system reset. I'd personally prefer the obscure place so I'm less likely to remove the keys as I'm cleaning up ~/Documents. Don't let me stop you from your idea, though. > > Regards, > Shinnok -- ------- inum: 883510009027723 sip: [email protected] xmpp: [email protected]
