| | 1 | = Computing preferences, version 2 = |
| | 2 | |
| | 3 | == Static and dynamic prefs == |
| | 4 | |
| | 5 | "Dynamic" prefs are parameters that limit BOINC activity, |
| | 6 | and that change in response to various factors. |
| | 7 | Examples include limits on #CPUs, RAM usage, network usage, etc. |
| | 8 | |
| | 9 | == Prefs dictionary == |
| | 10 | |
| | 11 | The "prefs dictionary" is a name -> value map, |
| | 12 | containing values that can affect dynamic prefs. |
| | 13 | Examples: |
| | 14 | |
| | 15 | * "idle_time": # seconds since last user input |
| | 16 | * "time": time of day |
| | 17 | * "on_batteries": whether system is running on batteries |
| | 18 | * "exclusive_app_running": whether an exclusive app is running |
| | 19 | * "non_boinc_cpu_usage": fraction of CPU used for non-BOINC apps recently |
| | 20 | |
| | 21 | These values are updated by the client. |
| | 22 | |
| | 23 | External programs can add items to the dictionary, |
| | 24 | and update their values, via GUI RPCs. |
| | 25 | Hence the prefs system is extensible without modifying the client. |
| | 26 | |
| | 27 | == Preference terms == |
| | 28 | |
| | 29 | Preferences are expressed in terms of "conditions" that are the conjunction |
| | 30 | of a set of "terms". |
| | 31 | |
| | 32 | Each term is an assertion about a dictionary item. |
| | 33 | There are three types of terms: |
| | 34 | |
| | 35 | * "greater than": the value of the item is greater than a threshold X. |
| | 36 | * "nonzero": the value of the item is nonzero (i.e. a true Boolean) |
| | 37 | * "time range": the value of the item (a time value) lies in a set of time intervals. |
| | 38 | |
| | 39 | A term can also have a "negate" flag, which if set reverses its sense. |
| | 40 | |
| | 41 | The XML representation of a term is |
| | 42 | {{{ |
| | 43 | <prefs_term> |
| | 44 | <item>item-name</item> |
| | 45 | <term_type>x</term_type> // 0 = greater than, 1 = nonzero, 2 = time range |
| | 46 | [<negate/>] |
| | 47 | [<thresh>x</thresh>] // if greater than |
| | 48 | [time range] // if time range |
| | 49 | </prefs_term> |
| | 50 | }}} |
| | 51 | and the representation of a time range is |
| | 52 | {{{ |
| | 53 | <time_range> |
| | 54 | <start_hour>x</start_hour> |
| | 55 | <end_hour>y</end_hour> |
| | 56 | [ |
| | 57 | <day> |
| | 58 | <day_of_week>x</day_of_week> |
| | 59 | <start_hour>x</start_hour> |
| | 60 | <end_hour>y</end_hour> |
| | 61 | <day> |
| | 62 | }}} |
| | 63 | == Conditions == |
| | 64 | |
| | 65 | A "condition" is the conjunction ("and") of a set of terms, possibly negated. |
| | 66 | XML format: |
| | 67 | {{{ |
| | 68 | <prefs_condition> |
| | 69 | [<negate/>] |
| | 70 | <prefs_term> ... </pref_term> |
| | 71 | ... |
| | 72 | </prefs_condition> |
| | 73 | }}} |
| | 74 | |
| | 75 | == Clauses == |
| | 76 | |
| | 77 | A "clause" is the combination of a condition and a set of dynamic prefs. |
| | 78 | XML format: |
| | 79 | {{{ |
| | 80 | <prefs_clause> |
| | 81 | <prefs_condition> ... </prefs_condition> |
| | 82 | <dynamic_settings> ... </dynamic_settings> |
| | 83 | <prefs_clause> |
| | 84 | }}} |
| | 85 | |
| | 86 | == Preference sets == |
| | 87 | |
| | 88 | A "preference set" is a list of clauses. |
| | 89 | XML format: |
| | 90 | {{{ |
| | 91 | <computing_prefs> |
| | 92 | <prefs_clause> ... </prefs_clause> |
| | 93 | ... |
| | 94 | </computing_prefs> |
| | 95 | }}} |
| | 96 | |
| | 97 | The semantics are as follows. |
| | 98 | We maintain a set X of dynamic settings, initially empty. |
| | 99 | the clauses are processed in order. |
| | 100 | For each clause C, we evaluate its condition. |
| | 101 | If the condition is true, we overwrite X with C's dynamic settings. |
| | 102 | At the conclusion, X is the dynamic settings to be enforced. |