Interactions between history library & innconf

Alex Kiernan alexk at
Tue Mar 6 18:53:30 UTC 2001

Russ Allbery <rra at> writes:

> Alex Kiernan <alexk at> writes:
> > Russ Allbery <rra at> writes:
> >> If we go the route of a HISsetopt, would it work to use a struct
> >> containing all the possible options rather than separate HISsetopt
> >> calls for each parameter?  That *might* reduce the number of calls
> >> needed...  particularly if HISgetopt was also supported.
> > My only concern with a struct based approach is we lose some of our hard
> > won data hiding (currently all anything external to the history library
> > knows about a history struct is that its `struct history;').
> Yeah, if there are parameters that we can't generalize.  Hm.  One of my
> earlier thoughts was to have makedbz have carnal knowledge of the
> underlying history database style, by giving it access at a lower level
> than the API perhaps, and letting the user configure various options via
> makedbz and encode them in the equivalent of history.dir.

Thats more or less the way I'm thinking at the moment; its what the
ovdb stuff does too, AFAICT. I don't much like it, but it seems like a
least resistance approach.

I'm going to play with it a bit more tomorrow & try to get something
which makes sense, then generate a patch, else I'll never get around
to it!

> One of the things I want to do with the new configuration parsing system
> is to make it really easy to handle configuration intended for a
> particular subsystem without needing another configuration file.

Strongly agree there - the current proliferation of config files is a

> > How about a variable argument approach:
> I don't really see any effective difference between this and a struct;
> you're still exposing the same internal details, just in the form of
> preprocessor magic constants instead of struct fields (which I'd argue is
> inferior because they're harder to debug).

Agreed. I think I decided that it was a mistake whilst walking to the
office the morning I wrote that!

Alex Kiernan, Principal Engineer, Development, Thus PLC

More information about the inn-workers mailing list