Hallvard B Furuseth wrote:
Backends can have options with the same name but very different
semantics, and so far this seems to be reflected in back-config
attribute names. That could get messy, in particular with contrib or
private backend modules written using some other backend as a template.
I think a config parameter's attribute name in general should be
something like 'olc(Db?)<backend>-<parameter>', unless the parameter is
expected to be used the same way in all backends that use it.
No hyphens in backend names.
Overlays use 'olc<overlay><parameter>'. Backends could do the same if
we are never supposed to have an overlay and a backend with the same
name... However, note that we could still get name conflicts if the
name of one overlay is the beginning of the name of another overlay.
'olc<overlay>-<parameter>' would be better.
Existing config parameters could keep their current names as secondary
names, but get new names as the first name.
I think name collisions are only a real problem in the old slapd.conf
syntax. For back-config, conceptually every backend and overlay is
governed by its own individual schema. (This fact isn't exposed anywhere
via subschemasubentries, but we can probably do something about that at
some point.) While it may be visually confusing to have the same
attribute names used for totally different purposes, there is no
ambiguity in the underlying code because the attributes' semantics are
totally dictated by their containing object.
We started to adopt the "<overlay>-<parameter>" syntax for slapd.conf
because we didn't have any other way to more finely denote configuration
context there. I think that was a simple design mistake, we should have
just extended the notion of "current backend" and "current database" to
"current overlay" and isolated directives that way. But in back-config
all of the context is explicitly isolated since everything is in
separate config entries, so everything is unambiguous.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/
