Can we create a new set of HSEvent.* enums for timers? If you register for VALUE_CHANGE today you get called once per second for every timer running on the system, since most plugins do not need to track the per second state of the timers, this creates a large overhead which contributes to the HSEvent queue full errors (2 timers runnings means all HSEvent handlers in all plugins TOTAL must complete in 500ms including the remoting costs or the queue will eventually overflow which leads to unpredictable experience for users)
If so, I'd suggest then documenting in the porting guide that you need to register for the new event type and handle it in your HSEvent callback. Plugin authors can check the HS version to know if they need to handle that case separately or (if they need it for some reason) handle it in the their 3.0 handler.
If so, I'd suggest then documenting in the porting guide that you need to register for the new event type and handle it in your HSEvent callback. Plugin authors can check the HS version to know if they need to handle that case separately or (if they need it for some reason) handle it in the their 3.0 handler.
Comment