[...]
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
*
