openldap-commit2devel@OpenLDAP.org wrote:
- Log -----------------------------------------------------------------
commit 842d1b5a17d19e17bcc420d972c310a416b2000b Author: Howard Chu hyc@openldap.org Date: Sun Aug 19 12:49:02 2012 -0700
Added delete support
Summary of changes: servers/slapd/back-meta/config.c | 233 ++++++++++++++++++++++++++++++++++++- servers/slapd/back-meta/init.c | 2 + 2 files changed, 228 insertions(+), 7 deletions(-)
This reminds me, we still don't have a clear policy on how cn=config should present settings that have their default value. Personally I would prefer that settings at their default value not be displayed. Unfortunately the semantics get rather muddled.
Deleting a value should always mean returning it to its default setting. In the case of back-meta, per-target configuration can be initially inherited from the base configuration. The question then is, when you've allowed a target config to take the setting from the base, do you expect future changes to the base to also change the targets? It's similar to the referential integrity problem. My feeling is that it's not worth the trouble to maintain such a thing. Which probably means we should always return all attributes and values in cn=config all the time, so that all values are explicitly configured.
Other opinions?