12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
|
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
|
-
+
-
+
|
plugin handling goes hand in hand with configuration management.
However it requires a structured field to avoid bulky definitions, yet
support enough variation.
Usually `config:` contains multiple indented lines, each being a
<acronym title="JSON, but quotes optional">JSOL</acronym>-dictionary.
### {
#### {
<style>
.cnt-tbl { background: #fcfcfc; }
.cnt-tbl th { vertical-align: top; text-align: left; }
.cnt-tbl td, .cnt-tbl th { padding: 5pt; border: 2px solid #f3f3f3; }
.cnt-tbl td, .cnt-tbl th { padding: 7pt; border: 2px solid #f3f3f3; }
</style>
<table class="cnt-tbl">
<tr>
<th><code>name:</code></th>
<td>associates some variable/constant/expression to a setting.</td>
</tr>
<tr>
|
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
|
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
|
-
+
|
</tr>
<tr>
<th><code>value:</code></th>
<td>just sets a default</td>
</tr>
</table>
### }
#### }
## Storage and key `name:`
Notably this scheme just defines a list of available options. It does **not**
prescribe if they're stored in an `.ini`, `.json`, `xml` or code file, or a database
perhaps.
Applications might utilize different stores even, and dispatch depending on
|