Hello, I was thinking about the methods provided by the timely functions and the timerservice and I am wondering if it makes sense to change them a little so they can cover a wider set of use case. Maybe I missed something completely obvious so please shoot me down in that case :)
Currently the user gets a TimerService to register timers that will in the future call the onTimer method. It is not completely obvious to me how would I implement a function that needs to trigger two types of callbacks in the future. If I get only one onTimer method I should be able to pass in some sort of parameter or flag so I can branch in my onTimer implementation. As parameters are not supported I am left with states that are scoped to the keys which is also pretty useless if I want to trigger different timed actions for the same keys. I know this is quite tricky but I see some alternative options: - The register timer method returns a unique (per key) timer id, so we can associate state with this id to fetch info about the timer registered. (We could also remove timers with this id and maybe add methods to remove all for the current key) - Allow the users to pass a custom parameter when registering the callback, and the parameter would be passed to the onTimer method - Allow users to pass custom callback functions when registering the timers, but this would mean we have to support some sort of context for accessing the state (like the window context before) - We could go for an annotation based API like in beam but thats probably not good to mix in the current ones I personally prefer the first one. What do you think? Regards, Gyula
