RE: commit: ldap/servers/slapd acl.c aclparse.c ad.c controls.c repl.c search.c sessionlog.c slap.h

["Howard Chu" <hyc@highlandsun.com>]

> -----Original Message-----
> From: Pierangelo Masarati [mailto:ando@sys-net.it]
> Sent: Monday, December 15, 2003 11:35 PM
> To: hyc@highlandsun.com
> Cc: openldap-devel@OpenLDAP.org
> Subject: RE: commit: ldap/servers/slapd acl.c aclparse.c ad.c
> controls.c
> repl.c search.c sessionlog.c slap.h
>
>
>
> > I was just thinking that we need this functionality, but
> it's missing
> > something - for an excluded objectclass, it should also be
> excluded from
> > modify operations, not just add. E.g., if someone does a
> modify to add
> > an excluded objectclass to an entry, that modification
> should be dropped
> > from the replog.
>
> I think I'm overlooking the potential for its semantics;
> I think there can be many applications.  I'll consider
> you suggestion.

Well, the full line of thought was something like - I'd like the replog to
have the same filtering mechanism available as back-ldap. I.e., the ability
to map attributes and objectclasses from local to remote, including mapping
certain values to <nothing>. Currently I get this functionality by using
slurpd to replicate to an instance of back-ldap, with the desired mappings
configured there. This is kind of messy because it requires a separate slapd
instance, due to the same naming context being re-used.

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