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 [email protected] > > 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 <[email protected]> wrote: > >> [email protected] wrote: >>> - Log ----------------------------------------------------------------- >>> commit 842d1b5a17d19e17bcc420d972c310a416b2000b >>> Author: Howard Chu <[email protected]> >>> 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? >> >>> --- >>> http://www.openldap.org/devel/gitweb.cgi?p=openldap.git >>> >>> >> >> >> -- >> -- Howard Chu >> CTO, Symas Corp. http://www.symas.com >> Director, Highland Sun http://highlandsun.com/hyc/ >> Chief Architect, OpenLDAP http://www.openldap.org/project/ >> > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
