Interactions between history library & innconf

Alex Kiernan alexk at
Tue Feb 27 08:44:55 UTC 2001

Russ Allbery <rra at> writes:

> Alex Kiernan <alexk at> 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 HISV6_SYNCINTERVAL ((1 + HISV6_METHOD) << 8) | 0)
#define HISV6_OTHEROPT ((1 + HISV6_METHOD) << 8) | 1)


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

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

More information about the inn-workers mailing list