On Fri, Mar 28, 2014 at 09:08:33PM -0400, Dmitri Pal wrote:
I would like to start with a few general comments.
About .merge.conf. I think the name has to contain the name of the
original config file, because there might be multiple different config
files in the same directory. I you really want to keep the '.' at the
beginning I would suggest .<conf_file_name>.merge.conf . But I would
suggest to drop the '.' because the merging rules are part of the
configuration and should not be hidden.
Additional I could imagine that people would like to have the merging
rules in the master config file, e.g. in special sections like
[__section_name_MERGE_RULES__].
I think currently most application which support having parts of the
configuration in separate files use the following scheme. They have a
central config file, e.g. /conf_path/app.conf, at a hardcoded
(changeable with command line options) place and a directory
/conf_path/add.d. What the application reads as configuration can be
seen as the result of
cat /conf_path/app.conf /conf_path/add.d/*
I would suggest to add this scheme as a default mode if no merge config
file is available with the following conditions:
- all files must start with a valid section header, i.e. each file has
to be valid ini file
- duplicated section names are not allowed, i.e. no merging of any kind
will be done
I think this will cover the majority of use cases without defining the
merging rules explicitly. And it would be possible to do this with the
current API, i.e. applications must be only linked against the new
version of libini to make use of configuration files in
/conf_path/add.d/*.
bye,
Sumit
--
Thank you,
Dmitri Pal
Sr. Engineering Manager for IdM portfolio
Red Hat Inc.
-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
_______________________________________________
sssd-devel mailing list
sssd-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel