Commit | Line | Data |
4536f655 |
1 | |
2 | Stem Cron System Design Notes |
3 | |
4 | Stem::Cron is designed to both supplant the standard OS cron and |
5 | extending it to support more useful time filters. The key difference |
6 | from the OS cron is that Stem::Cron sends a Stem message when it is |
7 | triggered instead of running a process. This message can be addressed to |
8 | any cell on any Stem hub and so it can cause any action to occur. To |
9 | emulate the OS cron, all the message needs to do is to trigger an |
10 | addressed Stem::Proc cell to spawn a process. |
11 | |
12 | |
13 | |
14 | Stem::Cron entries are similar to the OS cron. You can select a set of |
15 | time parts (minutes, hours, dates, months, days of week) to trigger the |
16 | entry and each part is a list which filters the triggers. Each minute |
17 | (run by infinite repeat timer) the list of cron entries is scanned. If |
18 | the current broken out time matches one corresponding value in each of |
19 | the parts of the entry, then the entry is triggered and its message |
20 | is dispatched. |
21 | |
22 | The cron entry is configured with name/value pairs which are the time |
23 | parts and the set of which values to trigger on in that part. If a time |
24 | is not specified, it is assumed to match all values for that time part |
25 | (like * in crontab). These two differences already make Stem::Cron |
26 | easier to configure than crontab. In addition, each Stem::Cron entry |
27 | must have a message value. This is sent when the cron entry passes all |
28 | of its time filters and gets triggered. The message can be any type, |
29 | carry any data and be addressed to any cell in the Stem network. |
30 | |
31 | Beyond the simple time filters of crontab, Stem::Cron allows you to |
32 | specify complex date descriptions such as last date of the month, first |
33 | weekday of the month, 2nd Thursday of the month, etc. |
34 | |
35 | Another feature I am looking at is not well defined but i have a use for |
36 | it. The log filters want to have a time based toggle so for example, you |
37 | can enable/disable sending logs to a pager at night by sending it the |
38 | right messages. By attaching those messages to properly configured cron |
39 | entries, you have automated managing the times when the log filter is |
40 | enabled/disabled. But there are several open design issues. First, what |
41 | is the initial boolean state of the log time filter? Maybe we should make |
42 | another boolean attribute: time_filter_enabled => 1. Then how often do |
43 | you send the boolean toggle messages? A normal cron time range would |
44 | send messages every minute from enable to disable time (huh?). or we can |
45 | just send the disable message on one tightly defined cron entry and the |
46 | enable on another. The initial boolean state is used and that will keep |
47 | the log filter in the right state. This time controlled boolean toggle |
48 | is a useful idea we can apply elsewhere. A module just for managing |
49 | these things could be a good idea. It would, of course, use Stem::Cron, |
50 | but it could be specialized in setting the cron entries up and other |
51 | stuff. |
52 | |
53 | Right now, Stem::Cron entries are only created in configuration |
54 | files. Creating remote entries would just require sending a config via a |
55 | message to the global Cron cell. |
56 | |
57 | Stem::Cron is a high-level layer above Stem::Event timers. The major |
58 | difference is that Stem::Event only uses callbacks, whereas |
59 | Stem::Cron only sends out messages. Also, Stem::Cron has a much more |
60 | powerful and flexible API for specifying the timing of these messages. |
61 | |
62 | Besides the emulation of the standard OS cron, Stem::Cron can send |
63 | out a message at a repeated interval which has a resolution of |
64 | seconds. |
65 | |
66 | TODO |
67 | |
68 | more testing |
69 | |
70 | fancy time parts. i have developed perl code that calculates most of |
71 | those dates so it should be simple to port the logic over to stem. |
72 | |
73 | timed boolean triggers needs more design work and then coding. |
74 | |
75 | Sending remote configs has not been developed yet but should be done |
76 | soon. should be generic and go into the Stem::Config module. |
77 | |
78 | |
79 | |
80 | |