Interactions between history library & innconf

[Russ Allbery]

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.

> The icdsynccount is harder, since its a significant change in the
> caller, The only place where its relevant is in innd, and thats already
> doing that check (in ARTpost), moving it there doesn't seem like a
> significant hardship. Alternatively I could pass that interval in
> through HISopen, or add a HISsetopt type interface. To be honest making
> the caller do HISsync feels like adding library policy to the caller & I
> really don't like that.

> Actually now I've though of HISsetopt, I'm inclined to go that way, but
> I'm mindful of Russ' comments elsewhere on the number of calls to get
> your API going...

> Opinions?

Hm.  I think you're right; the sync interval really does sound like
library policy and something that should be configurable but that should
be internal to the library.

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.

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