Michael Ströder wrote:
Howard Chu wrote:
> Seems like it would be a good idea to define a new option "glue-peer" or
> somesuch that allows multiple peer-level DBs to be glued together.
What exactly do you mean with peer-level DBs? I didn't get what
the idea is for...
Mainly for grafting OpenLDAP on top of an existing, poorly designed
someone-else's DIT.
> In case of duplicate entries, we'd have to track them and
either drop
> some of them or merge them.
Hmm...how about bind requests?
Good question.
I'm a very simple thinking guy. Therefore I'm not in favour
of
endorsing a setup which lets the slapd admins believe they don't
have to think about schema and names spaces and consolidation of
their data.
Also a good point.
How should duplicates be detected (by DN, by filter?) and based on
which criteria should they be dropped or merged. Even merging is
messy: Merge all attribute values of same attributes of all merged
entries? Or give some entries priority over others or I'm already
totally confused now... ;-)
Yeah, good questions. Perhaps it is better addressed by enhancing
slapo-translucent instead to allow local entries to exist independently of
remote ones. At least in that case, there is a clearly defined precedence.
(All local data overrides any remote data.)
--
-- Howard Chu
Chief Architect, Symas Corp.
http://www.symas.com
Director, Highland Sun
http://highlandsun.com/hyc/
Chief Architect, OpenLDAP
http://www.openldap.org/project/