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

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

Howard Chu wrote:

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

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

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

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.

> 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