New configuration parser ready

[Jeffrey M. Vinocur]

On Tue, 3 Sep 2002, Russ Allbery wrote:

> [ making sure that there are no unrecognized keys in the inn.conf file ]
> 
> Well, part of the problem is that the code isn't entirely written yet to
> obtain all of the keys used in a configuration block.  But that should be
> easy to fix.  (It's already stubbed in; I just haven't written it yet
> because I didn't need it for the first round of things.)

Ah.  (What's the interface to that look like?)


> The rest of the problem is that the new inn.conf parser uses a table of
> configuration parameters that would be checked against, and right now it's
> not sorted usefully because it's sorted by what portions of INN use
> various configuration entries to make it easier down the road to break the
> monolithic inn.conf apart into different configuration groups for
> different subsystems.  

Ah, sure.

It think I need to see what the interface to the entire generic parser is 
before I can really say anything useful.  So I'll just hold off until the 
commit.


> So it's a linear search for each parameter.

Making the whole thing quadratic.  Cute.


> If we wanted, though, we could discard or separately maintain the
> information about who uses what and pre-sort the table, at which point
> we can do a binary search and it's much faster.

If we're doing this inside the parser itself, then there are all sorts of 
interesting issues and possibilities.

Doing it outside though, potentially the easiest thing is to enumerate all
of the values in both sets, each into an array of strings, sort both 
arrays, and do a single pass (like a merge from mergesort but without 
actually bothering to merge them) in linear time checking if any keys are 
missing, duplicated, or unknown (if the parser doesn't catch unknown keys 
at an earlier point).  It's still total n log n, which is I believe the 
best you can do without using a hash table.


-- 
Jeffrey M. Vinocur
jeff at litech.org