I’ve updated the proposal to restrict the observe/notify calls to the same canister: as @oggy pointed out, there’s a way to call observe/notify on a different canister by that canister exposing a regular endpoint calling observe/notify on the management canister internally; this has the advantage of avoiding data races that could emerge from two different canisters calling the observe/notify endpoints on the management canister for the same event.
This is nice and gives a nice and simple event-based programming hook that you can use to build a simple eventing system.
It occurred to me if you couldn’t possibly get the “sleep” side of this by simply using the “one_shot” method that was used with motoko for avoiding hanging callbacks. I don’t know the details, but it was something to the effect that a one-shot would crate a callback pointing to a non-existant function(0 or -1 as a hook or something like that) so that it wouldn’t block an upgrade and/or would do nothing when the other canister replied.
If you called this no-op function that the replica just ignores with a bounded-wait, it will time out and throw after the wait. If you call a function that isn’t really there or that is a no-op, or even a no-assign so the canister doesn’t even wake up then you’d accomplish the sleep part of this wouldn’t you? And you wouldn’t have to add much(maybe anything) to the actual replica? Maybe just something to the rust SDK.
I haven’t tried it, but @ggreif and @claudio what would be your expected behavior of bounded waiting a local one-shot in motoko? Is this effective sleep? If you reset this after every call do you become un-upgradeable?
Such a call will quickly fail with an error, i.e., there won’t be any sleep.