contrib/libucl/README.md

   1 ## Introduction
   2
   3 This document describes the main features and principles of the configuration
   4 language called `UCL` - universal configuration language.
   5
   6 If you are looking for the libucl API documentation you can find it at [this page](doc/api.md).
   7
   8 ## Basic structure
   9
  10 UCL is heavily infused by `nginx` configuration as the example of a convenient configuration
  11 system. However, UCL is fully compatible with `JSON` format and is able to parse json files.
  12 For example, you can write the same configuration in the following ways:
  13
  14 * in nginx like:
  15
  16 ```nginx
  17 param = value;
  18 section {
  19     param = value;
  20     param1 = value1;
  21     flag = true;
  22     number = 10k;
  23     time = 0.2s;
  24     string = "something";
  25     subsection {
  26         host = {
  27             host = "hostname";
  28             port = 900;
  29         }
  30         host = {
  31             host = "hostname";
  32             port = 901;
  33         }
  34     }
  35 }
  36 ```
  37
  38 * or in JSON:
  39
  40 ```json
  41 {
  42     "param": "value",
  43     "param1": "value1",
  44     "flag": true,
  45     "subsection": {
  46         "host": [
  47         {
  48             "host": "hostname",
  49             "port": 900
  50         },
  51         {
  52             "host": "hostname",
  53             "port": 901
  54         }
  55         ]
  56     }
  57 }
  58 ```
  59
  60 ## Improvements to the json notation.
  61
  62 There are various things that make ucl configuration more convenient for editing than strict json:
  63
  64 ### General syntax sugar
  65
  66 * Braces are not necessary to enclose a top object: it is automatically treated as an object:
  67
  68 ```json
  69 "key": "value"
  70 ```
  71 is equal to:
  72 ```json
  73 {"key": "value"}
  74 ```
  75
  76 * There is no requirement of quotes for strings and keys, moreover, `:` may be replaced `=` or even be skipped for objects:
  77
  78 ```nginx
  79 key = value;
  80 section {
  81     key = value;
  82 }
  83 ```
  84 is equal to:
  85 ```json
  86 {
  87     "key": "value",
  88     "section": {
  89         "key": "value"
  90     }
  91 }
  92 ```
  93
  94 * No commas mess: you can safely place a comma or semicolon for the last element in an array or an object:
  95
  96 ```json
  97 {
  98     "key1": "value",
  99     "key2": "value",
 100 }
 101 ```
 102 ### Automatic arrays creation
 103
 104 * Non-unique keys in an object are allowed and are automatically converted to the arrays internally:
 105
 106 ```json
 107 {
 108     "key": "value1",
 109     "key": "value2"
 110 }
 111 ```
 112 is converted to:
 113 ```json
 114 {
 115     "key": ["value1", "value2"]
 116 }
 117 ```
 118
 119 ### Named keys hierarchy
 120
 121 UCL accepts named keys and organize them into objects hierarchy internally. Here is an example of this process:
 122 ```nginx
 123 section "blah" {
 124         key = value;
 125 }
 126 section foo {
 127         key = value;
 128 }
 129 ```
 130
 131 is converted to the following object:
 132
 133 ```nginx
 134 section {
 135         blah {
 136                         key = value;
 137         }
 138         foo {
 139                         key = value;
 140         }
 141 }
 142 ```
 143
 144 Plain definitions may be more complex and contain more than a single level of nested objects:
 145
 146 ```nginx
 147 section "blah" "foo" {
 148         key = value;
 149 }
 150 ```
 151
 152 is presented as:
 153
 154 ```nginx
 155 section {
 156         blah {
 157                         foo {
 158                                         key = value;
 159                         }
 160         }
 161 }
 162 ```
 163
 164 ### Convenient numbers and booleans
 165
 166 * Numbers can have suffixes to specify standard multipliers:
 167     + `[kKmMgG]` - standard 10 base multipliers (so `1k` is translated to 1000)
 168     + `[kKmMgG]b` - 2 power multipliers (so `1kb` is translated to 1024)
 169     + `[s|min|d|w|y]` - time multipliers, all time values are translated to float number of seconds, for example `10min` is translated to 600.0 and `10ms` is translated to 0.01
 170 * Hexadecimal integers can be used by `0x` prefix, for example `key = 0xff`. However, floating point values can use decimal base only.
 171 * Booleans can be specified as `true` or `yes` or `on` and `false` or `no` or `off`.
 172 * It is still possible to treat numbers and booleans as strings by enclosing them in double quotes.
 173
 174 ## General improvements
 175
 176 ### Commments
 177
 178 UCL supports different style of comments:
 179
 180 * single line: `#`
 181 * multiline: `/* ... */`
 182
 183 Multiline comments may be nested:
 184 ```c
 185 # Sample single line comment
 186 /*
 187  some comment
 188  /* nested comment */
 189  end of comment
 190 */
 191 ```
 192
 193 ### Macros support
 194
 195 UCL supports external macros both multiline and single line ones:
 196 ```nginx
 197 .macro "sometext";
 198 .macro {
 199      Some long text
 200      ....
 201 };
 202 ```
 203 There are two internal macros provided by UCL:
 204
 205 * `include` - read a file `/path/to/file` or an url `http://example.com/file` and include it to the current place of
 206 UCL configuration;
 207 * `try\_include` - try to read a file or url and include it but do not create a fatal error if a file or url is not accessible;
 208 * `includes` - read a file or an url like the previous macro, but fetch and check the signature file (which is obtained
 209 by `.sig` suffix appending).
 210
 211 Public keys which are used for the last command are specified by the concrete UCL user.
 212
 213 ### Variables support
 214
 215 UCL supports variables in input. Variables are registered by a user of the UCL parser and can be presented in the following forms:
 216
 217 * `${VARIABLE}`
 218 * `$VARIABLE`
 219
 220 UCL currently does not support nested variables. To escape variables one could use double dollar signs:
 221
 222 * `$${VARIABLE}` is converted to `${VARIABLE}`
 223 * `$$VARIABLE` is converted to `$VARIABLE`
 224
 225 However, if no valid variables are found in a string, no expansion will be performed (and `$$` thus remains unchanged). This may be a subject
 226 to change in future libucl releases.
 227
 228 ### Multiline strings
 229
 230 UCL can handle multiline strings as well as single line ones. It uses shell/perl like notation for such objects:
 231 ```
 232 key = <<EOD
 233 some text
 234 splitted to
 235 lines
 236 EOD
 237 ```
 238
 239 In this example `key` will be interpreted as the following string: `some text\nsplitted to\nlines`.
 240 Here are some rules for this syntax:
 241
 242 * Multiline terminator must start just after `<<` symbols and it must consist of capital letters only (e.g. `<<eof` or `<< EOF` won't work);
 243 * Terminator must end with a single newline character (and no spaces are allowed between terminator and newline character);
 244 * To finish multiline string you need to include a terminator string just after newline and followed by a newline (no spaces or other characters are allowed as well);
 245 * The initial and the final newlines are not inserted to the resulting string, but you can still specify newlines at the begin and at the end of a value, for example:
 246
 247 ```
 248 key <<EOD
 249
 250 some
 251 text
 252
 253 EOD
 254 ```
 255
 256 ## Emitter
 257
 258 Each UCL object can be serialized to one of the three supported formats:
 259
 260 * `JSON` - canonic json notation (with spaces indented structure);
 261 * `Compacted JSON` - compact json notation (without spaces or newlines);
 262 * `Configuration` - nginx like notation;
 263 * `YAML` - yaml inlined notation.
 264
 265 ## Performance
 266
 267 Are UCL parser and emitter fast enough? Well, there are some numbers.
 268 I got a 19Mb file that consist of ~700 thousands lines of json (obtained via
 269 http://www.json-generator.com/). Then I checked jansson library that performs json
 270 parsing and emitting and compared it with UCL. Here are results:
 271
 272 ```
 273 jansson: parsed json in 1.3899 seconds
 274 jansson: emitted object in 0.2609 seconds
 275
 276 ucl: parsed input in 0.6649 seconds
 277 ucl: emitted config in 0.2423 seconds
 278 ucl: emitted json in 0.2329 seconds
 279 ucl: emitted compact json in 0.1811 seconds
 280 ucl: emitted yaml in 0.2489 seconds
 281 ```
 282
 283 So far, UCL seems to be significantly faster than jansson on parsing and slightly faster on emitting. Moreover,
 284 UCL compiled with optimizations (-O3) performs significantly faster:
 285 ```
 286 ucl: parsed input in 0.3002 seconds
 287 ucl: emitted config in 0.1174 seconds
 288 ucl: emitted json in 0.1174 seconds
 289 ucl: emitted compact json in 0.0991 seconds
 290 ucl: emitted yaml in 0.1354 seconds
 291 ```
 292
 293 You can do your own benchmarks by running `make test` in libucl top directory.
 294
 295 ## Conclusion
 296
 297 UCL has clear design that should be very convenient for reading and writing. At the same time it is compatible with
 298 JSON language and therefore can be used as a simple JSON parser. Macroes logic provides an ability to extend configuration
 299 language (for example by including some lua code) and comments allows to disable or enable the parts of a configuration
 300 quickly.