Re: [Tarsnap GUI] RFC: Automatic job backup and more

[jungle Boogie <jungleboogie0@gmail.com>]

Hi Shinnok,
On 23 June 2015 at 00:56, Shinnok <admin@shinnok.com> 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: jungleboogie@sip2sip.info
xmpp: jungle-boogie@jit.si