Features
Slack/buffer defaults
As of version 0.1.1, missing time values are set with ratios 3,4,5; see Schedule::Activity. As an improvement, support passing these 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.
Attributes
As of version 0.1.1, attributes are available in activity/action configurations and reported with buildSchedule. Future versions may support node filters, ie conditional logic predicated on the current attribute values during the build, such as next node look-ahead filtering (with fallback). Based on the nature of filtering, a nodal change at a given time may induce a rebuild of all following times (or the entire containing activity).
Multimessage support
As of version 0.1.1, messages can be strings, arrays, or a hash of alternates. Messages are chosen randomly. Message attributes are reported with the overall attribute results from buildSchedule. Attributes may be used in the future for filtering and searching.
Flat configurations
As of version 0.1.1, basic Markdown can be imported via Activity::loadMarkdown and supports randomization, and time specifications for activities and actions.
Annotations
As of version 0.1.1, annotations are secondary/tertiary schedules that are predicated on the primary list of activity/actions. After the actions have been scheduled, additional messages are inserted into the schedule either "before" or "after" existing events. For example, in an exercise schedule, a message to change the background music is an annotation and not part of the primary schedule.
Configuration is defined in Schedule::Activity::Annotation. The insert functionality is still only "proposed" and may be unnecessary. Additional functionality might be added to prevent clashes across multiple annotation groups.
Annotation Attributes
As of version 0.1.1, annotations may contain attributes but they are not reported with the attributes from buildSchedule and must be managed by the caller.
Convenience, min/max/valid reporting functions
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. Recommend some convenience functions to 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).
Tension
Scheduling tension is currently only available for buffer time, but it should also be configurable for slack time.
Node filtering
Node activation conditional upon current attribute values and, possibly, upon total node counts (to avoid the overhead of needing one attribute per node to track this). Each filter=[...] could therefore have entries of nodecount=>name,op=>value or attribute=>name,op=>value, where the op keys are the literal key names as eq, gt, ... (converted to numeric operators during evaluation). This would permit easier "gating operations", which currently require branch duplication in the configuraiton.
State
Actions can change states based on the path chosen. Those states may affect choices during later schedule builds. This would be useful for "consumables". This may be indistinguishable from attribute filters like "where sum(attribute)<1".
Command line tool
Something of the form schedule-activity.pl --schedule=file.dumper --activity='600,name' --activity='300,name' ... might be useful.
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/.
Action limits
As a special case of Attributes, a shortcut of the form limit=N can be supported. While the case limit=1 is not the primary/initial use case of the scheduler, it makes sense that some events would specifically never be repeated. Implementation requires Attributes and Node filtering, above, so this is not the highest priority on the list.
Imports for common patterns
There are three use cases that cannot currently be provided as examples.
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.
Functional improvements
Object interface
Move Schedule::Activity from static functions to an object interface.
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
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 buildSchedule, 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.