Ups, yes, I mean
FYI, the Timer is implemented on top of the ScheduledCompletableFuture, see openhab-core/TimerImpl.java at 93a8a214cf3a790c2464bd4475512e758cab9e63 · openhab/openhab-core · GitHub.
Timers can be used by any language by access the methods from core, but it is not possible to modify or overwrite the
createTimer method due to its usage of xtext. I am not sure if xtext is required, it is possible to implement the functionality without using xtext, but there is some difference in the behaviour when using a Java Runnable or Callable instead of an xtext Procedure.
Nothing converts the JS functions passed. The problem of the Procedure is not that we couldn‘t use it from the JS runtime, but to make
createTimer threadsafe we need to wrap the callback in the Java layer of add-on, and this is the point where we have the problem with xtext.
Yes, as already said, I don‘t think that it requires an Xtend/Xtext Procedure, instead a Java Runnable or Callable should also work. But changing that could possibly change the behaviour of create timer regarding variables passed, and therefore a core change there could break Rules DSL as well as other engines.
You are talking about the next problem: when Rules DSL becomes its own addon at some time, we don’t have access to the actions anymore (as long as they don’t stay in core), and therefore createTimer is gone as well.
Yes, I think so. It is very likely that it would make it possible.
The overall problem with the createTimer from core is, that it is from core and we have very limited control over it in the addon and it is part of Rules DSL (at least seems to be for me), and the future of Rules DSL is unclear. If it becomes an addon, we don’t have access to its methods anymore.
I agree on your opinion — I think the best solution is to implement something new to manage timers, it should be easy to use, work with JS and provide the functionality needed for advanced users.
Even though this is a larger addition on top of standard JS and the openHAB core APIs, I agree that we need something like that. And to be fair, for the toZDT method of time we also added some stuff in the helper library that provides additional functionality.
I’ve seen your proposal of such a manager, I agree on the functionality that is required.
I’d like to have the following implemented:
- Support for retrieving additional information like isCancelled etc. for timers created by setTimeout and setInterval
- A builder like API to create timers (for advanced users), the question here is: do we want automatically manage the jobs created by this API, leave it to the user or let the user decide what to do?
Both changes require some changes in the addon, but I can contribute there as well.
I‘ll try to propose some solution this weekend.