Overview
Before 0.4.0
The following are planned as part of the 0.4.0 release.
- (todo) Tutorial and samples extended for recent features
- (todo) Script incremental build, retained materialized annotations
- (todo) Attribute::Report end-of-activity values
- (todo) Timing multipliers per activity
- (todo) Annotation overall closeness control
- (todo) Attribute initial values via
schedule()and commandline - (todo) Tension in outer scheduling step
Features
Goals
Value-based goals.
Attributes
Attribute reporting using activity boundaries. The attribute reporting grids based on timestamp should support columns that show the values at the end of each activity.
JSON output from the script is being considered, and would include JSON renderings of the attribute outputs.
Node filtering
Nothing planned at this time.
Annotations
Annotation filtering. Some annotations may occur before an action but not when after certain other actions. Annotations should support node filtering for this situation.
Annotations may also benefit from a schedule-wide closeness configuration.
Scheduling
Incremental scheduling support for materialized annotations per-activity.
Global time multiplier. In some cases, buffer is insufficient to create an "expanded schedule". For example, if an activity is 50% longer than configured, the usual behavior is to repeat actions. A global time multiplier would increase tmmin/tmavg/tmmax to support stretching an activity without needing a new configuration.
Tension configuration
Tension should also be configurable in the outer scheduling step. This would permit incrementally relaxing the scheduler in case of retries. No timeline has been established.
Tutorial
Many new features are not demonstrated in the tutorial.
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
No known issues at this time.
Markdown
As part of a general review of import and export mechanisms, basic Markdown support needs updated to support some of the new features. Some samples below suggest possible custom import functions.
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
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.
Backtracking behavior
The current mechanism is primarily for safety. Better backtracking support should be possible.
Performance
Both processing time and memory have been secondary considerations in initial versions. Some optimizations are possible, particularly with rolling averages and the main scheduling algorithm.
Validation
There are always more checks to be performed on the configuration.