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.
But... that's kind of theoretical. Just because KDL and JSON can represent it, doesn't mean I should, too. I make up the syntax and its limitations here.
Had a short¹ adventure in the forest, which I spent in deep thought². Upon reflecting those, and the replies in this thread, my current thinking is that I'll keep the strict checking for now, but if that ever becomes annoying (either for users, or for me, preparing a new version), I'll either introduce a switch to make config verification more lax, or do so by default (and introduce a --strict option or something).
¹: "It's only 2kms!", they said. More like 10km.
²: By which the author means he was busy trying to stay awake, because he was dumb enough to stay up till 4 in the morning.
Okay, lets consider an iocaine config with Nam-Shub of Enki config embedded in it.
http-server "main" {
bind "/run/iocaine.socket" unix-socket-access=group
handler "/path/to/nam-shub" {
inherits "default"
logging { enable #true; }
checks {
enable demo commercial-scrapers
disable cgi-bin-trap
demo { host "iocaine-demo.example.com"; }
}
sources {
wordlists "/some/path"
training-corpus "path1" "path2" "..."
}
}
}
I think this looks fine. Technically, the lists could be represented as:
training-corpus {
- "path1"
- "path2"
"..."
}
But I like the brace-less representation more, so I'm not going to treat "-" as a special marker. It will be treated as a regular key, repeating it will override the previous value, like it does with any other name.
The other question is if I should allow named properties in the handler config block, like foo bar=baz, az a short for foo { bar baz; }. I... don't want to.
Likewise, while technically valid, and can be mapped to JSON, I don't want to allow node-name 1 2 { foo bar; } either. In those spaces, nodes can have either positional arguments or children, not both, and named props are disabled.
Yes, this limits the shape of the handler configuration somewhat, but makes it less ambigous, imo. The handlers are not KDL aware, and I'm not going to make them KDL aware either.
A space for Bonfire maintainers and contributors to communicate