[Date Prev][Date Next]
Re: Moving backends to table-driven config...
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
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
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
SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
Symas: Premier OpenSource Development and Support