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?
Sorry for top post. What about returning the defaults only with manage dsa set like with dynlist?
-- Kind Regards,
Gavin Henry. Managing Director.
T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry@suretec.co.uk
Open Source. Open Solutions(tm).
http://www.suretecsystems.com/
Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 24 Cormack Park, Rothienorman, Inverurie, Aberdeenshire, AB51 8GL.
Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html
Do you know we have our own VoIP provider called SureVoIP? See http://www.surevoip.co.uk
On 19 Aug 2012, at 21:14, Howard Chu hyc@symas.com wrote:
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?
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Gavin Henry wrote:
Sorry for top post. What about returning the defaults only with manage dsa set like with dynlist?
An interesting idea. Unfortunately the way things currently work, it's not practical. The config entries are not built on-the-fly for each search request, they're held persistently in memory (and in the underlying back-ldif). They would need to be built on the fly to react to the ManageDSA control as you suggest.
-- Kind Regards,
Gavin Henry. Managing Director.
T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry@suretec.co.uk
Open Source. Open Solutions(tm).
http://www.suretecsystems.com/
Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 24 Cormack Park, Rothienorman, Inverurie, Aberdeenshire, AB51 8GL.
Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html
Do you know we have our own VoIP provider called SureVoIP? See http://www.surevoip.co.uk
On 19 Aug 2012, at 21:14, Howard Chu hyc@symas.com wrote:
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?
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
-
Gavin Henry -
Howard Chu