Struct interval_schedule_data



// In header: <fd/interval_schedule_definition.h>

struct interval_schedule_data {
  // construct/copy/destruct
  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;  // 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/destruct

  1. interval_schedule_data();
    Construct yet invalid schedule.
  2. explicit interval_schedule_data(interval_granularity granularity);
    Construct unnamed schedule with one starting point within the given granularity.
  3. 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 members

  1. int repetitions;

    0 means unlimited.

  2. 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

  3. 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

  4. 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.