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

[Howard Chu <hyc@symas.com>]

I wasn't sure I was ready for this yet, haven't decided if the current 
attribute-based callbacks are sufficient for a proper schema-enforced 
Modify operation. But I guess we can dive in and see what happens...

Pierangelo Masarati wrote:

> Howard,
>
> I'd like to start moving back-ldap and maybe some other backend to 
> table-driven configure, and there's a couple of issues I'd like to 
> clarify before I start.
>
> 1) In back-bdb, you added a bdb_back_init_cf() function; I don't 
> understand its need: in fact it's just called inside 
> bdb_back_initialize(), so my guess is that you wanted to keep the 
> bdbcfg structure static and confined in the config.c module.  Is this 
> correct?

Yes. I've been trying to keep all of the config-related stuff isolated, 
to prevent additional dependencies on config.h, since it is still 
somewhat fuzzy.

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

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?

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