I agree that we need to be pragmatic about what features to leave in or out of the system. In this case I lean towards the system providing this functionality leading to the simplest and most efficient implementation compared to an implementation in application-space.
And conversely, if it is impractical to use a canister to provide cron services to many canisters, then that smells like a failure of the Internet Computer to achieve the vision behind it. So if “cron canisters” don’t work now, we should maybe use this to improve the system to make them work, rather than giving up and stuffing more features into the core components.
That’s exactly what I am suggesting we do, improve the system to make cron canisters work. Any cron canister is going to rely on the heartbeat functionality if it is to run entirely on the IC. How I suggest we do this is change the system to allow canisters to register when the heartbeat function should be called, instead of calling it nearly every second on every canister that has a registered heartbeat function.
It doesn’t seem to me that a lot of information would need to be stored by the system per canister to achieve this, and hopefully it could just be stored in the canister’s memory space somehow.
In my experience with heartbeat it is simply too course and expensive to use nicely. Any canisters spun up to provide cron services to other canisters will become incredibly expensive to run and will reach the scalability limits of a single canister performing many cross-canister calls per heartbeat function.
The design of the heartbeat is too course right now, and I think a relatively simple improvement at the system level could make the feature much more usable.
There is definitely something wrong with heartbeat, various people are smelling it:
- Cycle burn rate heartbeat
- Why does a canister keep consuming cycles? - #7 by PaulLiu
- @bob11’s experience at Toniq