Interactions between history library & innconf

[Alex Kiernan]

Russ Allbery <rra at stanford.edu> writes:

> Alex Kiernan <alexk at demon.net> writes:
> 
> > I've got two dependencies on innconf in the history stuff, one for the
> > type of history you want ("hismethod") and one for sync interval
> > ("icdsynccount").
> 
> > Having the hismethod one inside the API means you can't open two
> > different history implementations at the same time, which feels wrong -
> > not least to do a convert you have to implement that in the library,
> > rather than as an external iterator + writer. I'm inclined to make the
> > hismethod setting a parameter passed into HISopen so that you can
> > control this from the caller directly.
> 
> 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?

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

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

then

if (!HISsetopt(history, HISV6_SYNCINTERVAL, 100, HIS_GENERICTHING, 20,
        HIS_LASTARG)) {
    /* handle error */
}

if (!HISgetopt(history, HISV6_SYNCINTERVAL, &interval, HIS_OTHERPARM, &other,
        HIS_LASTARG)) {
    /* handle error */
}

Its not type safe (which I don't much like), but might be a reasonable
compromise.

I think you'd want a number of history API level options (although I
can't actually think of any off hand) and a number of per history
implementation options (like sync interval).

-- 
Alex Kiernan, Principal Engineer, Development, Thus PLC