Interactions between history library & innconf

[Russ Allbery]

Alex Kiernan <alexk at demon.net> writes:
> Russ Allbery <rra at stanford.edu> writes:

>> I think that's the best approach to start with.  Eventually, I'd like
>> to somehow autodetect the history file type so that you only have to
>> specify the type when creating a new history file.

> Something like an is_this_yours() type interface internal to the history
> API?

Yes, exactly.

>> 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.

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.  For
example, with the new parser system, one should be able to put a block in
storage.conf for cycbuffs like:

cnfs {
    refresh: 40
    update: 30

    cycbuff ONE { path: /path/to/cycbuff/one ; size: 100000 }
    cycbuff TWO { path: /path/to/cycbuff/two ; size: 100000 }

    metacycbuff META {
        cycbuffs: "ONE, TWO"
        mode: sequential
    }
}

and all the other storage methods will ignore it and the CNFS storage
method can get all the data it needs without needing a separate
cycbuff.conf and its own parser.

We could take that same approach here eventually.

> How about a variable argument approach:

> #define HISV6_METHOD 0

> bool HISgetopt(struct history *, ...);
> bool HISsetopt(struct history *, ...);

> #define HIS_LASTARG 0
> #define HIS_GENERICTHING 1

> #define HISV6_SYNCINTERVAL ((1 + HISV6_METHOD) << 8) | 0)
> #define HISV6_OTHEROPT ((1 + HISV6_METHOD) << 8) | 1)
> ...

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).

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>