Re: Moving backends to table-driven config...

[Pierangelo Masarati <ando@sys-net.it>]

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 
> > else.
>
>
> 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 
> suggestions.

I suggest:

- OLcfg -> 1.3.6.1.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 
specialization.

If this sounds reasonable, I can start renaming schema objects.

p.

> > > 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: 
> > +390382476497



   SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497