it has to be told about all the registered alarms by all apps again after restarting
Is that true? Or does it just read from the rtc state? (Or leave it alone?) Also for efficiency reasons, don't you want a single wakeup being scheduled rather than potentially spaced out wakeups?
stored settings
Aka a database, right? Albeit a per-user database. What you are talking about sounds more like a service (daemon) than an app, though, from my perspective. A sort of per-user waked. That operates by holding timerfds it negotiated away from a privileged service. You can't revoke FDs anymore/yet, right? Although you can mark them cloexec and go on a killing spree.
I just want the timer to fire and be handled in the process where it's needed, regardless if the system is suspended or not completely transparently. Waked doesn't help with that. I certainly don't want a special daemon that I have to register with over a complicated protocol (d-bus) in addition to having to manage the timers in app when it can be avoided just by passing a single flag to timerfd_create which will work universally and will not depend on systemd.
Spliting alarms into a deamon and UI shell is kinda pointless unless some other app would need access to alarms. But that would be a different service than waked in any case. Waked doesn't handle timers.
Is that true? Or does it just read from the rtc state? (Or leave it alone?) Also for efficiency reasons, don't you want a single wakeup being scheduled rather than potentially spaced out wakeups?
stored settings
Aka a database, right? Albeit a per-user database. What you are talking about sounds more like a service (daemon) than an app, though, from my perspective. A sort of per-user waked. That operates by holding timerfds it negotiated away from a privileged service. You can't revoke FDs anymore/yet, right? Although you can mark them cloexec and go on a killing spree.