[Date Prev][Date Next] [Chronological] [Thread] [Top]

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

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:


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