[Date Prev][Date Next]
Re: Moving backends to table-driven config...
Howard Chu wrote:
2) What is the config schema numbering plan (if any)? I see that in
bconfig.c you are using "OLcfgAt:<digit>", while in back-bdb you're
using "OLcfgAt:1.<digit>", and in back-ldif you simply recycle the
"dbDirectory" attribute of back-bdb. Should we use a different
prefix for different backend types, e.g. a "OLcfgAt:2.<digit>" for
back-ldap, recycling stuff in back-meta and so, to allow independent
development with minimal conflict resolution? I also note that
"OLcfgAt:1" right now is "olcAccess", while "OLcfgAt:1.1", i.e.
"olcAccess.1" is "dbDirectory"...
Yes, I wanted to recycle the common terms for back-bdb and
back-ldbm, and since back-ldif had only a single parameter I reused
that one as well. But for other backends, you can define new ones or
recycle as you deem fit. The schema loaders will silently ignore
redundant attempts to define the same item.
The general idea was that OLcfgAt and OLcfgOc were for the
core/global config items, and everything else would have a sub-arc
under those. Part of the reason to use objectIdentifier macros here
is that we can easily reassign entire segments of the schema later
when a more logical arrangement surfaces. It may make more sense to
use a separate arc under OLcfg for the backends and overlays, to
keep them out of the core space. Haven't really seen any advantage
one way or another.
SO would you suggest to keep the OLcfgAt.1. branch for backends, or
futher specialize? I don't see big issues in coordination, because
at some point we need to converge to an agreed numbering and that's
going to be it, no more changes. One thing about names: the olc*
prefix looks fine; other names, like dbDirectory (in general, the db*
prefix) sounds a bit too generic and likely already in use by someone
I suggest using a new branch for back-ldap/meta, rooted at OLcfg. I'll
move back-bdb as well. As for a prefix, I suppose we could just use
olc* for everything. Or olb* for backends/databases. I'm open to
- OLcfg -> 18.104.22.168.4.1.4203.666.11.1 (as of today)
- OLcfgAt -> OLcfg:3 (as of today)
- OLcfgOc -> OLcfg:4 (as of today)
- global stuff rooted at OLcfgAt:0 and OLcfgOc:0 (i.e., "olcAccess"
would be OLcfgAt:0.1 and so on)
- backend stuff could be rooted at OLcfgAt:1 and OLcfgOc:1
- common backend stuff could be rooted at OLcfgAt:1.0 and OLcfgOc:1.0
- each backend type could have an assigned branch for specific
configuration directives (e.g. back-bdb could get OLcfgAt:1.1 and
OLcfgOc:1.1, back-ldap could get OLcfgAt:1.2 and OLcfgOc:1.2 and so on)
- overlay stuff could be rooted at OLcfgAt:2 and OLcfgOc:2
- common overlay stuff could be rooted at OLcfgAt:2.0 and OLcfgOc:2.0
- each overlay could have an assigned branch for specific configuration
directives (e.g. glue could get OLcfgAt:2.1 and OLcfgOc:2.1 and so on).
The only rationale behind this is that there would be a clear separation
between what is global, what is common to all backends and what is
specific to each backend; moreover, each backend would have an OID
assigned. There are grey areas represented by commonality across
backend types (I'm thinking od back-bdb and back-ldbm, or back-ldap and
back-meta); in these cases, the common directives could go into one of
the backends and get shared by the others, or they could go into the
common backend-specific branch, or so. In fact we already have
"generic" backend-specific directives that only apply to a subset of
backends: the "index" or even the "suffix" directive (back-monitor and
back-config do not allow suffix), so moving the "dbDirectory"
attributeType to the backend-generic branch sould not be an issue.
With respect to attribute/objectClass prefix, I suggest "olc*" for
common stuff; "olcDb" for backend-generic and "olcOv*" for
overlay-specific, so we save the "olc*" common prefix and add a level of
If this sounds reasonable, I can start renaming schema objects.
Somewhat on this topic, currently the OID macros aren't preserved in
the actual schema elements that use them. While we never expose them
in the cn=Schema subentry, I think it would make sense to preserve
them in the back-config data. Yes?
I agree; we could keep track of the objectidentifiers defined, and
consistently trap all OIDs that are rooted at one objectidentifier
and rewrite them using the objectidentifier when presenting
back-config data; I think this should add clarity because (well
designed) strings are more readable than dotted digits. Of course,
the rewriting should go from specific to general; sorting them by
string length should suffice.
SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax:
SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497