Interactions between history library & innconf
alexk at demon.net
Tue Mar 6 18:53:30 UTC 2001
Russ Allbery <rra at stanford.edu> writes:
> Alex Kiernan <alexk at demon.net> writes:
> > Russ Allbery <rra at stanford.edu> 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
> 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