Builtin and inheritance code are removed. The way it will work now will
be specific to options, view and zone clauses. Materialization will be
used. In otherwords, 3 versions of the config co-exists:
- the builtin (the one hard-coded)
- the user (the one coming from named.conf)
- the running
The running configuration is a copy of the builtin one, and on top of
that, a copy of the user one overriding values already existing from the
builtin one. Then, each modifications applied override it.
In order to keep things simple initially, the next changes will be:
- removal of lists: the API feels brittle, it's non deterministic order
(might be problematic), it enforces a size of values to 511 bytes, and
it's very specific to LMDB implementation. The better approach will
need to be found later.
- removal of "repeatable clauses" this concepts was to be able to
iterate over views and zones, but it forces to have random IDs
generated for clause names, which make materialization over-complex.
(i.e. the ID for a clause "x" in the builtin wouldn't be the same in
user or running, and would force some cotortions).
Short term: removal of newclause/nextclause, this will also break
validation. This will need to be addressed. Probably by having an extra
LMDB DB which tells the list of top-level keys from a given prefix, so
we would be able to quickly jump from one clause to another.
Colin Vidal
34f9de111a