perl-ldap-dev

Suggested Schema changes

[Graham B. <gb...@po...>]

I think the root of the problems with Schema.pm is that ->item is used as
an accessor for all types, and the the internal structures are wrong.
Also The methods return names or OIDs, which them must be passed to item
to retrieve.

Here is what I propose

Internals

  $schema = {
    # OID will be a hashref mapping the OID (number or un-altered name) to the hash
    # which holds the elements data
    oid => { ... },

    # at will be a hash mapping the lower case version of the names and aliases
    # of attributes to the hash for the element
    at  => { ... },

    # Same as at for all other types
    etc..
  };

The API then needs to change.

We do away with ->item and make is_attribute return the element hash. This way we know
that the given name/OID should be an attribute or syntaxrule or whatever. If we
really want to hide the contents of the element hash, then we should just bless it
into another package which contains accessor methods.

So now instead of

  $href = $schema->item('userName');
  $syn  = $schema->item('userName','syntax');

you will do

  $href = $schema->is_attribute('userName');
  $syn  = $schema->is_attribute('userName')->{syntax};

However, I dont really like the is_ prefix on these methods, but dropping that makes
the name too close to existing methods (attributes) which return all attributes,
so if anyone has any ideas (or they do not think it will be a problem), then fire away.

Graham.

Re: Suggested Schema changes

[Graham B. <gb...@po...>]

On Mon, Jan 07, 2002 at 02:36:34PM +0000, Graham Barr wrote:
> I think the root of the problems with Schema.pm is that ->item is used as
> an accessor for all types, and the the internal structures are wrong.
> Also The methods return names or OIDs, which them must be passed to item
> to retrieve.
> 
> Here is what I propose
> 
> Internals
> 
>   $schema = {
>     # OID will be a hashref mapping the OID (number or un-altered name) to the hash
>     # which holds the elements data
>     oid => { ... },
> 
>     # at will be a hash mapping the lower case version of the names and aliases
>     # of attributes to the hash for the element
>     at  => { ... },
> 
>     # Same as at for all other types
>     etc..
>   };
> 
> The API then needs to change.
> 
> We do away with ->item and make is_attribute return the element hash. This way we know
> that the given name/OID should be an attribute or syntaxrule or whatever. If we
> really want to hide the contents of the element hash, then we should just bless it
> into another package which contains accessor methods.
> 
> So now instead of
> 
>   $href = $schema->item('userName');
>   $syn  = $schema->item('userName','syntax');
> 
> you will do
> 
>   $href = $schema->is_attribute('userName');
>   $syn  = $schema->is_attribute('userName')->{syntax};
> 
> However, I dont really like the is_ prefix on these methods, but dropping that makes
> the name too close to existing methods (attributes) which return all attributes,
> so if anyone has any ideas (or they do not think it will be a problem), then fire away.

In fact it seems that what I was trying to describe is similar to the Java API.

For those not familiar with it, see

http://docs.iplanet.com/docs/manuals/dirsdk/jsdk41/Reference/index.html

And look at the LDAPSchema and LDAPSchemaElement class definitions.

Graham.

Re: Suggested Schema changes

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

Graham Barr <gb...@po...> wrote:
> On Mon, Jan 07, 2002 at 02:36:34PM +0000, Graham Barr wrote:
>> I think the root of the problems with Schema.pm is that ->item is used as
>> an accessor for all types, and the the internal structures are wrong.
>> Also The methods return names or OIDs, which them must be passed to item
>> to retrieve.
>> 
>> Here is what I propose
>> 
>> Internals
>> 
>>   $schema = {
>>     # OID will be a hashref mapping the OID (number or un-altered name)
>>     to the hash # which holds the elements data
>>     oid => { ... },
>> 
>>     # at will be a hash mapping the lower case version of the names and
>>     aliases # of attributes to the hash for the element
>>     at  => { ... },
>> 
>>     # Same as at for all other types
>>     etc..
>>   };
>> 
>> The API then needs to change.
>> 
>> We do away with ->item and make is_attribute return the element hash.
>> This way we know that the given name/OID should be an attribute or
>> syntaxrule or whatever. If we really want to hide the contents of the
>> element hash, then we should just bless it into another package which
>> contains accessor methods.
>> 
>> So now instead of
>> 
>>   $href = $schema->item('userName');
>>   $syn  = $schema->item('userName','syntax');
>> 
>> you will do
>> 
>>   $href = $schema->is_attribute('userName');
>>   $syn  = $schema->is_attribute('userName')->{syntax};
>> 
>> However, I dont really like the is_ prefix on these methods, but
>> dropping that makes the name too close to existing methods (attributes)
>> which return all attributes, so if anyone has any ideas (or they do not
>> think it will be a problem), then fire away.
> 
> In fact it seems that what I was trying to describe is similar to the
> Java API.
> 
> For those not familiar with it, see
> 
> http://docs.iplanet.com/docs/manuals/dirsdk/jsdk41/Reference/index.html
> 
> And look at the LDAPSchema and LDAPSchemaElement class definitions.

Yes, that sounds about right. I'm slightly unhappy with the methods being
called 'is_*' given this usage:

$schema->is_attribute('userName')->{syntax};

I prefer the Netscape method naming style, although it does mean that there
will be different methods with very similar names ('getAttribute' returning
a single definition and 'etAttributes' returning an enumeration).

How about 'attribute' for the single definition, and 'all_attributes' for,
well, all of them?

Cheers,

Chris