Timer Logic

We'd like to manage timers server-side with convenient and fool proof client-side controls. github


A timer will be active if it has a setInterval running.

An item will render as inactive if it doesn't have a properly configured timer running. A 'start' button will activate.

Active timers should survive page reloads and server restarts. A serve-side table and persisted json asset will track active timers. See More About Datalog Assets

Start timers according to schedule.

Work out multiple recordings based on page title.

Retire logs that exceed keep period.

Login required to start or stop.

Refuse to start from browser local copy? Refuse to even poll server for status? github

Don't intermix schedules between farm sites. github


A timer will confirm that the initiating page and item are still present and set right. One might revert to an earlier configuration. Async read? More sample jitter?

Add a timer status option that reconciles schedule.json with running timers and returns links to pages that have timers running.

Multiple servers serving the same content can/will activate simultaneous timers and append redundant samples to the log. How bad is this?

Multiple active timers per page will share the same asset folder. They may append redundant samples and compete to retire logs. How bad is this?

Issue: returning to open plugin after server restart the button action fails and disables until reload. This is because the site hasn't started so xhr fails.

Notice active state change that doesn't coincide with page refresh. Update button. But how? When?