Re: Net::LDAP::schema brokenness

[Chris R. <chr...@me...>]

"Kurt D. Zeilenga" <Ku...@Op...> wrote:
> Edited for clarity:
> 
> At 10:54 AM 1/29/01 -0800, Kurt D. Zeilenga wrote:
>> My suggestion is to have three routines:
>> 
>> subschema( targetDN ) which reads the subschema contained in the
>> entry (or subentry) named by the targetDN.  This would do a base
>> search of the targetDN with the filter (objectClass=subschema) and
>> specifically request the return of attribute types describing
>> the schema elements.
>> 
>> subschemasubentry( targetDN ) which returns the DN contained
>> as a value of the subschemaSubentry attribute type within
>> the entry (or subentry) named by the targetDN. Would return error
>> if multiple values of subschemasubentry exist (subschemasubentry
>> is a single valued attributed type).
>> 
>> schema( DN ) [named this for historical purposes] which is
>> a basically a shortcut for
>>        subschema( subschemasubentry( targetDN ) )
>> 
>> Note this would return an error if the root DSE subschemasubentry
>> contained multiple values.  This is a FEATURE as the user needs
>> to select the correct one manually to obtain the appropriate
>> schema.
>> 
>> Kurt

Thanks for the comments.

In fact, my change of yesterday is incorrect because it accidentally used
the X.500 subschema operational attributes instead of the LDAP ones. (In
X.500 attributeTypes and objectClasses etc are operational attributes on
every entry.)

Your suggested API looks sensible. It permits caching of schema objects,
which is a Good Thing as they're reasonably expensive to keep transferring
from the directory and parsing in the client. They're also fairly large
objects to have to keep creating :-)

Here's a revised patch. It implements a cache which appeared to work in my
test. I'm not entirely certain what the desired semantics of the old
subschema() method were (this was probably apparent from my previous
message :-), so have left that method alone. The cache is keyed on subentry
DN, and includes a timestamp which is either the subentry's modifyTimestamp
(if it has one) or createTimestamp (if it has one).

It needs migrating to the 0.22 API, but that's fairly trivial. There's a
minor problem because the code 'knows' what attributes the
Net::LDAP::Schema class requires, but that's fixable too.

Cheers,

Chris