Glen Choo <chooglen@xxxxxxxxxx> writes: > ... In the spirit of > libification, this feels like a kludge, though, since we'd be reverting > to using "struct repository" for more things instead of using more > well-scoped interfaces. If you include "populate from system-wide, per-user, and repository specific configuration files" as part of the API being libified, your configsets cannot avoid being tied to a repository. But I do not think the reader needs to be in the repository. > IMO a better future for the config_set API would > be to move it into configset.c or something, where only users who want > the low level API would use it and everyone else would just pretend it > doesn't exist. Isn't the use of the reader object purely transitory while you populate the keys and values in a configset from a single file? At the layer to read and populate a configset from a single "source" file, you still do not need repository. Only when you say "I have a 'repo' instance and I want to read the config variables from appropriate places", you call such a "read and populate configset from a single source" helper three or four times to populate repo->config. Once a configset is populated, it or its contents do not depend on the reader instance to function, so I do not see how it benefits to have the reader in the repository object.
