hyc@OpenLDAP.org wrote:
Update of /repo/OpenLDAP/pkg/ldap/servers/slapd
Modified Files: config.c 1.488 -> 1.489
Log Message: Use underscore in network_timeout
I figured since this hadn't been documented yet I could change it without repercussions. But it raises a question of consistency; we have some options using hyphens, and some using underscores, and I don't really see any rationale for which is chosen. Anyone have a preference, and a reason?
<quote who="Howard Chu">
hyc@OpenLDAP.org wrote:
Update of /repo/OpenLDAP/pkg/ldap/servers/slapd
Modified Files: config.c 1.488 -> 1.489
Log Message: Use underscore in network_timeout
I figured since this hadn't been documented yet I could change it without repercussions. But it raises a question of consistency; we have some options using hyphens, and some using underscores, and I don't really see any rationale for which is chosen. Anyone have a preference, and a reason?
The majority things use hyphens don't they?
Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 13 Whiteley Well Place, Inverurie, Aberdeenshire, AB51 4FP.
--On Thursday, May 08, 2008 4:49 AM -0700 Howard Chu hyc@symas.com wrote:
hyc@OpenLDAP.org wrote:
Update of /repo/OpenLDAP/pkg/ldap/servers/slapd
Modified Files: config.c 1.488 -> 1.489
Log Message: Use underscore in network_timeout
I figured since this hadn't been documented yet I could change it without repercussions. But it raises a question of consistency; we have some options using hyphens, and some using underscores, and I don't really see any rationale for which is chosen. Anyone have a preference, and a reason?
I strongly prefer hyphens. In part because they are treated as word boundaries in vi. ;)
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Howard Chu writes:
I figured since this hadn't been documented yet I could change it without repercussions. But it raises a question of consistency; we have some options using hyphens, and some using underscores, and I don't really see any rationale for which is chosen. Anyone have a preference, and a reason?
One fix is to translate '-' to '_' internally in slapd.conf option names, or to ignore both. Inconsistent with ldap.conf keywords though. Could do the same there, but then we must walk through all environment variables instead of using getenv(), I don't know if that is possible on all supported OSes.
Hallvard B Furuseth wrote:
Howard Chu writes:
I figured since this hadn't been documented yet I could change it without repercussions. But it raises a question of consistency; we have some options using hyphens, and some using underscores, and I don't really see any rationale for which is chosen. Anyone have a preference, and a reason?
One fix is to translate '-' to '_' internally in slapd.conf option names, or to ignore both.
In the primary keywords (argv[0]) we can do this easily enough; we can just provide table entries for the valid alternate forms. For secondary keywords, I don't think there's an easy way to do it uniformly.
Inconsistent with ldap.conf keywords though.
I don't see any pressing reason to change that.
Howard Chu writes:
Hallvard B Furuseth wrote:
One fix is to translate '-' to '_' internally in slapd.conf option names, or to ignore both.
In the primary keywords (argv[0]) we can do this easily enough; we can just provide table entries for the valid alternate forms. For secondary keywords, I don't think there's an easy way to do it uniformly.
I agree.
Come to think of it, one disadvantage of ignoring '-' and '_' rather than treating them as the same: It somewhat increases the chance of name clashes with option names in overlays. These are typically prefixed with '<overlay name>-', exactly in order to avoid name clashes. Without the '-' the initial letters of some unrelated slapd.conf keyword might be the same. A programmable overlay (e.g. a perl overlay) could even claim all option names starting with '<overlay name>-'.
Inconsistent with ldap.conf keywords though.
I don't see any pressing reason to change that.
OK.
Hallvard B Furuseth wrote:
Come to think of it, one disadvantage of ignoring '-' and '_' rather than treating them as the same: It somewhat increases the chance of name clashes with option names in overlays.
Yepp. The parameter's prefix should be prepended with a separator (either by hyphen or underscore). Otherwise one has to maintain a prefix code.
Ciao, Michael.
Michael Ströder wrote:
Hallvard B Furuseth wrote:
Come to think of it, one disadvantage of ignoring '-' and '_' rather than treating them as the same: It somewhat increases the chance of name clashes with option names in overlays.
Yepp. The parameter's prefix should be prepended with a separator (either by hyphen or underscore). Otherwise one has to maintain a prefix code.
True for now, but I expect this sort of consideration to be less important going forward, as we emphasize cn=config and deprecate slapd.conf.
Howard Chu writes:
Michael Ströder wrote:
Yepp. The parameter's prefix should be prepended with a separator (either by hyphen or underscore). Otherwise one has to maintain a prefix code.
True for now, but I expect this sort of consideration to be less important going forward, as we emphasize cn=config and deprecate slapd.conf.
The same goes for all of this discussion. The cn=config attribute names use neither '-' nor '_'.
In any case, deprecating slapd.conf looks to be years in the future to me. It's much easier to read and write (correctly:-) than cn=config, and so are things like replacing an included schema version. Though you could take slapd.conf support out of slapd right now and instead make a separate slapconf tool which translates it to cn=config.
Hallvard B Furuseth wrote:
Howard Chu writes:
Michael Ströder wrote:
Yepp. The parameter's prefix should be prepended with a separator (either by hyphen or underscore). Otherwise one has to maintain a prefix code.
True for now, but I expect this sort of consideration to be less important going forward, as we emphasize cn=config and deprecate slapd.conf.
The same goes for all of this discussion. The cn=config attribute names use neither '-' nor '_'.
True, but they don't need special prefixes because their attributes are context-sensitive. I.e., their behavior is totally dependent on what config entry they appear in.
In any case, deprecating slapd.conf looks to be years in the future to me.
Agreed, I'm talking long term, not overnight.
It's much easier to read and write (correctly:-) than cn=config,
I think that's only because we all have 10+ years experience with slapd.conf files. If you read the steps in openldap.ldif it's really not that hard to get used to the LDIF format.
and so are things like replacing an included schema version.
Not sure I agree with that... Considering that you can do it on the fly with cn=config, and you can also replace the individual schema.ldif files if you're working offline.
Though you could take slapd.conf support out of slapd right now and instead make a separate slapconf tool which translates it to cn=config.
No need to take that step.
Howard Chu wrote:
Michael Ströder wrote:
Hallvard B Furuseth wrote:
Come to think of it, one disadvantage of ignoring '-' and '_' rather than treating them as the same: It somewhat increases the chance of name clashes with option names in overlays.
Yepp. The parameter's prefix should be prepended with a separator (either by hyphen or underscore). Otherwise one has to maintain a prefix code.
True for now, but I expect this sort of consideration to be less important going forward, as we emphasize cn=config and deprecate slapd.conf.
Until now my understanding was that slapd.conf is still supported for all upcoming 2.4 releases.
So if you don't want to prevent new parameters from being supported in slapd.conf you have to either maintain a prefix code covering all parameters or use a separator for defining a separate name space for each overlay. Just stripping separators is an information loss.
BTW: I prefer slapd.conf since it makes documentation (operational concept) and change management in projects much easier.
Ciao, Michael.
-
Gavin Henry -
Hallvard B Furuseth -
Howard Chu -
Michael Ströder -
Quanah Gibson-Mount