Features
Tentative Version Changes
- 0.1.9
-
unsafe=0will be the default.buildSchedulewill warn about deprecation. - 0.2.0
-
buildSchedulewill be removed; only the object interface will be supported.
Scheduling
Multiple proposals are being considered for rescheduling, scheduling adjustment to target different attributes, as well as attribute-level goals. Other feature improvements below are related to scheduling.
Message support
No additional features planned. Messages can be strings, arrays, a hash of alternates, a named message key, or a hash named message. Named messages are supported for action nodes and annotations. Attributes are supported in hash-alternate configurations and within named messages.
Attributes
Planned improvements include helpers to merge annotation attributes into schedules, additional reporting functions, and automatic mapping of attributes for some action node parameters (eg limits). As of 0.1.2, attributes are fully supported in messages and action nodes. As of 0.1.3, precedence has been established for node/message attribute overlap. As of 0.1.5, average values have moved to a rolling algorithm to improve efficiency, which means that no historic/past entry of a value is possible.
Annotations
Planned improvements include helpers to merge annotation attributes into schedules. Proposed is annotation configuration per-node (with a keyname, possibly duplicated in the upper-level configuration). As of 0.1.2, annotation groups are fully supported.
Node filtering
Node filtering is experimental starting in 0.1.6. Filters support Booleans and attribute numeric comparisons. Average value filtering should work but is not well tested. Because per-node limits differ between limit-per-activity and limit-per-schedule, it's not clear that a special mechanism will be created to provide these limits, which can be achieved by setting the attribute to zero at the appropriate point and filtering normally.
Near-buffer limitation
Fixed in 0.1.7. See "BUGS" in Schedule::Activity. If a conclusion node can be reached, there are more circumstances where it should be chosen to complete scheduling. The arithmetic for available buffer time should be updated to include the tmmax of the final node, where applicable.
Tutorial
In addition to the samples listed below, a tutorial is planned to take an existing, linear schedule, and deconstruct it into activities/actions, messages, and annotation groups. As of 0.1.6, work has begun on a tutorial!
Action limits
The case limit=1 is not the primary/initial use case of this scheduler, but some events will likely never be repeated. This can already be achieved by setting the attribute to zero initially, incrementing as appropriate, and then filtering. Because there's a difference between limit-per-activity and limit-per-schedule, it's not clear that a special mechanism will be created.
Tension configuration
Fully available in 0.1.8. Scheduling tension supports configurable slack/buffer values. Tension settings affect path selection, but the scheduler will fail for the fullpath if there is insufficient slack/buffer to adjust the path to the goal time. This may change in the future, namely the tension settings may permit scheduling completion even if the measured slack/buffer wouldn't otherwise permit adjustment.
Slack/buffer defaults
As an improvement, support passing slack/buffer ratios during configuration building. Eventually it will be helpful to pass slack/buffer defaults as part of schedule building: Having a value used during schedule building would permit relaxation during retries, and could be reported with the result. This requires changing assumptions in the validators.
Pre-scheduling safety
Built in 0.1.7. Off by default in 0.1.8 with unsafe=1, and supported from schedule-activity.pl --unsafe. More complex schedules may be difficult to interpret at a glance. One particular annoyance is finding that the target time for an activity cannot be reached, or that there are too many actions to fit a smaller goal window. Convenience functions find the minimum possible activity time (shortest path through the nodes, ultimately), if the activity can be completed at all (sorta easy to forget, and should be checked before attempting scheduling), and the maximum possible activity time (if defined). Moreover, these checks are needed to avoid hanging nodes (that don't reach finish), or action nodes with zero times (that never make progress), orphans, etc.
Script-based tooling
Available in 0.1.8, basic schedule-activity.pl script supports Dumper/JSON schedules and activity lists, compiling with/out safety checks. Future support may provide for common schedule types: Music playlists (high count, non-redundant nodes), exercise schedules (chunking, some repeats), chores/errands (small action count per activity/category), games (rounds, countdown reminders).
Annotation handling has not been determined. Options will likely include materialization into the returned message stream, or separate sections.
Markdown
Basic Markdown support is likely to change in non-backwards-compatible ways. A written proposal might be posted to ensure support for the common use cases that would aide with faster definitions and imports.
Sample text to speech tool
An HTML+Javascript solution utilizing Web text to speech already exists to handle reminders for schedules of the form hh:mm:ss message # comment and could be provided in samples/.
Additional samples
First, something like a music playlist is similar to the base case here. This is a "large number of random choices" but "each is very fixed in time length". There are multiple potential actions to be randomized. Music has attributes (mood). Scheduling can be arranged in chunks (activities), so there are natural groupings for an arrangement. Scheduling requires Action limits, above, so currently this is slightly difficult and/or requires a helper import mechanism to build the schedules. Moreover, the slack/buffer mechanisms operate 'backwards', in the sense that music+pause periods are fixed and may be impossible to schedule within a fixed/given window of time (hence the common patterns of advertisements between songs and fade-in/out techniques). It's not clear that an arithmetic equivalent of fading will ever be supported in this library. Nevertheless, a "playlist import" type mechanism to build the configurations would be helpful.
Second, something like holiday activities. This is a "small number of choices" but "each is very fluid in length" and has limit=1. An import tool for this type of request should be rather easy, but Action limits are a prerequisite.
Third, scheduling of paired events is not straightforward. An example would be match-off lineups of N teams (eg fantasy leagues). That is less a concern of temporal scheduling and more about uniformity in the lineup. This is possible by running two simultaneous builders on the same configuration, with very fixed times, but may result in self-alignment of activities. It's not clear that this type of scheduling will ever be supported in this library.
Fourth, this may be useful as a test generation tool. The prove command already supports shuffling, but for load and performance testing it's often useful to rerun test workloads and workflows in seemingly random order. This mimics traffic patterns more accurately since similar requests can appear frequently. Nothing in the existing code mandates the unit of time as "seconds", and message objects can be used to represent sequential tests, or a queue potentially offloaded to a number of parallel workers.
Functional improvements
Validation and configuration build
Attribute registration is getting messy; needs more helpers, particularly for pulling attributes out of message objects. Validation of named messages, and even messages themselves, is flakey.
Object interface
Move Schedule::Activity from static functions to an object interface. This is likely to occur when moving to 0.2.0.
Pre-scheduling validation
Scheduling shouldn't be attempted if it's impossible to achieve the goals. As per the suggested convenience functions above, verify that the minimum path time and max path times bound the activity goal time.
Annotation validation
Annotations need better pre-scheduling validation and better separation from the main scheduling code. Currently unclear of the best place to provide those helpers, as well as annotation-group-merging functions and the associated configurations.
Slackless/Bufferless configurations
Goals can never be met if slack/buffers are zero and the activity time requested doesn't exactly match action choices. This should likely fail with an error similar to the convenience functions mentioned above.
Support full object configurations
The current validation logic assumes plain hash references in several spots, but a user should be able to build an object-oriented collection of Nodes etcetera and still call schedule, without manually overriding the pre-validation flag.
Backtracking behavior
The current mechanism is primarily for safety. Better backtracking support should be possible.
Validation of tmmin/avg/max
Validation should check that values are non-decreasing.