On Mon, Dec 24, 2001 at 09:40:03AM -0800, Ryan Bloom wrote: > I thought of another reason to do this in the tree itself. The point of the config > tree is to keep the current config in memory. If you are going to modify the > config, you need to modify it in the tree. By doing to work on the tree, you > get that for free.
I'm confused (it may just be the eggnog :), but aren't we talking about two different things? There are fatal and non-fatal errors in the config. We want to give a meaningful message when we discover a fatal error, but we just want to issue a warning and try to adjust something sane for non-fatal errors. I can see how fidgeting with absurd settings by rearranging the order in the tree will make it easier to deal with some of the non-fatal errors, but doesn't it seem easiest to deal with the fatal errors all at once after we've got a stable config tree with all the defaults in place in the tree? -aaron