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

["Pierangelo Masarati" <ando@sys-net.it>]

>> -----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.

I see.  I'll consider other implications of !objectClass.

Ando.

-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it