search

sandstorm-io / sandstorm

Sandstorm is a self-hostable web productivity suite. It's implemented as a security-hardened web app package manager.
https://sandstorm.io
Other
6.7k stars 704 forks source link

Make it easier for apps to manage scheduled jobs. #3522

Open zenhack opened 3 years ago

zenhack commented 3 years ago

While working on #3519, I discovered that TTRSS doesn't re-create the background task after being clone or restored from backup (https://github.com/zenhack/ttrss-sandstorm/issues/25). Right now this is because it markes the job as having been created on first run. We don't want to just unconditionally create the job, since you'd end up with an extra job after every start.

It would be nice to find a way to make managing this kind of thing easier for apps.

One possible design: we could add an id field or such to ScheduledJob, and if sandstorm receives a job with an ID that's already in the database, it would replace it, rather than creating a separate job. This way, apps could use the id to make job scheduling idempotent, so they don't have to worry about whether or not the job has already been created.

ocdtrekkie commented 3 years ago

I am feeling some competing designs here for this, I feel we should nail down what is expected.

If we treat scheduling a job like a capability, I'd expect scheduling Cron jobs to require user input, at least to grant the permission to create scheduled jobs. In that scenario, I'd expect you to be able to revoke them in grain settings, and an app would have to request permission to create them again. For apps that can schedule a bunch of jobs, or one-time jobs like calendar reminders, this might be an issue.

If we treat scheduling a job like just a feature of the app platform (like keeping the app awake is), the app should just silently re-register itself whenever it wants to, if the grain is cloned or whatever. In this scenario, the button in #3519 makes no sense: You might delete a scheduled job, but the next time anyone opens the grain, it re-schedules it, defeating the point of letting you decide to remove it. In this scenario, the more sensible way to handle grain settings would be a toggle, where you can enable and disable letting the grain execute scheduled jobs, but accepting that individually removing them is pointless. (It'd still be useful to display them, but we'd accept that apps can/should recreate them if they're missing, so user removal is pointless.)

In short, either we should make allowing scheduled jobs a capability/permission requiring user input, and allow the user to delete that permission, or we should continue to let apps schedule as they please, but allow the user to block an app from using the functionality in a toggle format.

zenhack commented 3 years ago

fwiw, wake locks don't require user input to grant, but do trigger a notification with the ability to revoke.

Previous discussion: https://github.com/sandstorm-io/sandstorm/pull/2922#issuecomment-561365864

I think we came to the conclusion that a permission prompt for background jobs was too awkward, but that a wake-lock style notification might make sense -- which we never implemented, perhaps we should.

A per-grain toggle might indeed make more sense than per-task cancel.

ocdtrekkie commented 3 years ago

Yeah, I think I still agree with that. While I think it's probably more complicated a feature, I think we should avoid having the user delete scheduled jobs at all, since grains will recreate them, and have the user block the grain from executing any of the jobs it schedules instead.

zenhack commented 3 years ago

Ok, so soonish I'll swap out the cancel buttons for a disable toggle, and at some point we'll add the notification as well.

But that still leaves this issue. I do like the id field solution.