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

[Howard Chu <hyc@symas.com>]

Pierangelo Masarati wrote:

> On the other side, I wanted to make some changes to back-ldap 
> configuration with respect to target URI/identity assertion selection, 
> and I didn't want to do the work twice: now andwhen moving to 
> table-driven...

Ok, makes sense.

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

> > 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


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