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

[Howard Chu <hyc@symas.com>]

Pierangelo Masarati wrote:

> 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.
OK, go ahead.

--
 -- Howard Chu
 Chief Architect, Symas Corp.       Director, Highland Sun
 http://www.symas.com               http://highlandsun.com/hyc
 Symas: Premier OpenSource Development and Support