[Date Prev][Date Next]
RE: commit: ldap/servers/slapd acl.c aclparse.c ad.c controls.c repl.c search.c sessionlog.c slap.h
>> -----Original Message-----
>> From: Pierangelo Masarati [mailto:email@example.com]
>> Sent: Monday, December 15, 2003 11:35 PM
>> To: firstname.lastname@example.org
>> Cc: openldap-devel@OpenLDAP.org
>> Subject: RE: commit: ldap/servers/slapd acl.c aclparse.c ad.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.
I see. I'll consider other implications of !objectClass.