directory-api mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthew Swift <Matthew.Sw...@Sun.COM>
Subject Re: Let's start for real ?
Date Fri, 27 Nov 2009 11:07:34 GMT
> [...]
> DN : I would rather use Dn
> RDN : Same her, Rdn sounds better to me
> AVA : idem, Ava
> Entry : fine
> Attribute : fine, except that it collides with JNDI attributes, making
> the JNDI ->  new API translation cumbersome. EntryAttribute ?
> Modification : Fine
> Control : Fine
> LdapURL : LdapUrl has my preference
> AttributeType : Fine
> DitContentRule : Fine
> DitStructureRule : Fine
> MatchingRule : Fine
> MatchingRuleUse : Fine
> NameForm : Fine
> ObjectClass : Fine
> Syntax : Fine, or LdapSyntax
> ResultCode : Fine
> OID: Oid for me
> CSN: Csn again, same reason
>    

I'm happy with those, except that I prefer uppercase (LDAPURL looks 
pretty ugly though).

I'm not sure of the value of OID or CSN in an LDAP SDK (especially the 
latter).

A data type that we have found particularly useful is 
AttributeDescription since this is a structured object (type + options) 
with precise syntax and matching semantics (e.g. options must be sorted) 
and which is used widely in LDAP. It is then possible for apps to cache 
these types if they want to save on repeated parsing:

    public final class AttributeDescription {

       // Uses default schema.
       public static AttributeDescription valueOf(String s) throws
    IllegalArgumentException { ... }

       // Uses user provided schema.
       public static AttributeDescription valueOf(String s, Schema
    schema) throws IllegalArgumentException { ... }

       // Various convenience methods
       public boolean isSubtypeOf(AttributeDescription a) {...}

       public boolean containsOption(String s) {...}

       // As well as hashCode, equals, compareTo, and toString
    }


Then we have:

    public interface Entry {

       ...

       Attribute getAttribute(AttributeDescription a);

       // Implicit AttributeDescription.valueOf(attributeDescription);
       Attribute getAttribute(String attributeDescription) throws
    IllegalArgumentException;

    }


We don't require that the client API has a schema available. The default 
schema can be either the built in standard "core" schema (e.g. cn, sn, 
etc) or it could even be the built in "empty" schema, both of which fake 
up missing attribute type definitions on demand (in which case they use 
octet string syntax and equality matching). This is nice because it 
means that the API does not need get bloated by having two API 
abstractions (non schema aware and  schema aware).

Here's some other types that you'll probably need:

    * Filter - this is the raw Filter structure defined in RFC 4511
      protocol def. We also have a Matcher object (in the style of the
      Regex APIs) which represents a Filter compiled against a
      particular schema.
    * Assertion - represents an attribute value assertion compiled by a
      MatchingRule - typically these are stored in a compiled Filter
      (Matcher)
    * Schema - a container of attribute types, object classes, etc
    * ByteString and/or AttributeValue - you'll need at the bear minimum
      a ByteString for storing attribute values. You may decide that you
      need an AttributeValue as well in order to cache the normalized
      form, but I don't think that it's necessary and it just bloats the
      API and memory - the Attribute can cache normalized forms.
      Matching rules will need to normalize bytes. For such a low level
      primitive it's best to use an immutable object for this. We also
      have a ByteSequence and ByteStringBuilder in the same manner as
      CharSequence, StringBuilder, and String.
    * Search scope (needs to be extensible - i.e. not an enum)
    * Modification type (needs to be extensible - i.e. not an enum)
    * Dereference aliases policy
    * Condition result for filters (true, false, undefined)

Matt


    *


Mime
View raw message