Has there been talk about allowing something similar to scheduled cron jobs to call zome functions on behalf of an agent?
When running an hApp on your local holoport/holoraspberry-pi/oldmacmini you can offcourse configure an actual cron job to run. But when installing an hApp from the hApp store or running it through Holo I guess there is a different situation?
Will hApp bundles be able to contain more than compiled DNAs and static UI resources? Like additional node.js / bash scripts to be run upon installation of hApp. I can think of a number of reasons why that would be a really bad idea but it would also allow for some pretty cool apps.
In the meantime, some kind of simplified cron mechanism configurable in the zome definition or similar would go a long way.
Some sort of cron-like functionality is a frequent request actually. I like these questions you’re asking, cuz it means you’re digging deep into the consequences of Holochain’s design for real life apps. That’s an encouraging sign!
I think the use case would steer the implementation. What sorts of scenarios are you picturing for cron jobs?
Yes I think we would eventually want something more then static UI and DNA. It could also be a binary that is run as a middleware.
The long running issue is a bit harder to solve. You could solve it if everyone running the hApp was also running this “middleware” which was capable of distributing any long running tasks across the network of middlewares. I think this would not be trivial though.
The ability to pack UI, middleware and DNA as one bundle and Holoports hosting/serving all three layers would be great! It would make a strong case businesswise for Holo/hosts as well, not having to rely on third party middleware setups for many applications.
Long running threads I wouldn’t see as a main requirement, rather regular middleware waking up when called or at certain intervals performing tasks.
