fd::interval_schedule_data
// In header: <fd/interval_schedule_definition.h> struct interval_schedule_data { // construct/copy/destruct interval_schedule_data(); explicit interval_schedule_data(interval_granularity); explicit interval_schedule_data(interval_granularity, std::wstring); // public data members std::wstring name; // Optional schedule name. bool inactive; // Whether schedule is inactive. onset_series_blueprint blueprint; // Blueprint type denotes how to handle and generate onset time points. interval_spec interval; interval_spec subinterval; std::vector< interval_onset > cycle; // series of correlating onsets form a cycle. schedule_timepoint active_from; // Beginning of activity frame. schedule_timepoint active_until; // End of activity frame. int repetitions; // Fixed maximum number of repetitions. interval_onset_duration duration; // Optional execution span of an onset's action. bool skip_delayed_intervals; // Whether to skip onset time points delayed by previous actions. std::any appdata; // Miscellaneous data the application needs to store additionally. };
A schedule definition describes a cycle of recurring series of onsets or pairs of onsets on a certain interval scale (granularity), possibly confined to a finite activity boundary and an optional explicit onset action duration (execution span).
The schedule definition will be later turned into a timepoint generator, see schedule_timepiece.
There's no specific action associated with the onset itself except for an optional explicit duration (i.e. an interval is due, marking the next starting point for some action, possibly end-of-life). The type of action at this starting point depends entirely on the context and has to be defined and associated outside of the schedule.
interval_schedule_data
public
construct/copy/destructinterval_schedule_data();Construct yet invalid schedule.
explicit interval_schedule_data(interval_granularity granularity);Construct unnamed schedule with one starting point within the given granularity.
explicit interval_schedule_data(interval_granularity granularity, std::wstring name);Construct schedule with one starting point within the given granularity.
interval_schedule_data
public
public data membersint repetitions;
0 means unlimited.
interval_onset_duration duration;
If set this value denotes either an absolute duration or a relative period before end of the next onset. (i.e. of the onset action happening between intervals). The value should be less than or equal to interval length (in other words: within resolution of granularity); in case of subinterval blueprints the duration value is capped, respectively the relative period is counted from the next onset timepoint.
A special value of 0 means empty/unspecified and has the effect that the duration is as long as the interval between generated onsets; In this case it's upon the consuming application to decide the meaning - e.g. simply ignore it or treat is e.g. as a restart
bool skip_delayed_intervals;
purpose: imagine you configure a duration - for a defacto restart; assume that stopping takes a longer time, the next interval has already begun and the next action is therefore overdue; this option is considered only for the last interval, i.e. possible further gaps are always skipped
std::any appdata;
This method has the following advantages:
encapsulates the need for sundry data at a single point.
keeps the main focus on the schedule.
keeps the application free from alternatives, which require more effort, such as book-keeping in additional variables or tuple packing (which is especially cumbersome for a list of schedules).
E.g. FireDaemon Pro uses is to store a flag to distinguish between fixed 'uptime' and 'downtime' duration schedules.