Post
Continuing where I left off last night, I've been wondering: what to do about unknown, unexpected properties or nodes?
In the current implementation, they're errors. But all other configuration sources silently ignore everything that isn't a syntax error.
I'm tempted to keep this strictness, because half the time those unexpected properties are a syntax error. Not a syntax error for KDL, but a syntax error for iocaine's use of KDL.
For example, bind @iocaine.socket "127.0.0.1:42069" is valid KDL, but bind requires a string, not a Vec...
...come to think of it, the other config sources would also bail in this case, because this would fail to deserialize. They'd accept and ignore unknown keys, though. Perhaps I should do that: ignore unknown keys, including unknown properties, as long as other invariants hold.
bind "127.0.0.1:42069" "@iocaine.socket would still be an error, but handler "/some/path" foo=bar would not: bind requires a single string, handler accepts properties - we just ignore the unknown ones. Consequently, handler "/some/path" "/foo/bar" would also need to fail, because only a single positional argument is accepted.
With that said... I think I'm gonna roll unix-listen-access into bind:
server main {
bind "/run/iocaine.socket"
unix-listen-access group
}
=>
server main {
bind "/run/iocaine.socket" unix-socket-access=group
}
Another reason to keep the strictness is the handler configuration. Only a subset of KDL is allowed there that maps reasonably cleanly to JSON.
Mngh. There's at least one case where my KDL -> figment::Value mapping fails.
foo {
- bar
- baz
quux
}
should map to foo = ["bar", "baz", "quux"], I think.
I don't quite handle "-" well as the node name. I literally handle it as "-", rather than "any node name".
Tbh, I'm not sure I like this part of JiK. I think my "json-in-kdl" will have stricter, different requirements. I don't want to support foo prop1=val prop2=val in that part of the config, either, only foo { prop1 val; prop2 val; }.
On the other hand, not supporting the - node name nor props might backfire:
items {
- id=1234 foo=1
id=4321 {
options { foo bar; }
}
}
This should work, to represent a list of objects.
A space for Bonfire maintainers and contributors to communicate