Ok, so we can start with : DN RDN AVA Entry Attribute Modification Control AttributeType DitContentRule DitStructureRule MatchingRule MatchingRuleUse NameForm ObjectClass Syntax ResultCode
Still to be decided : LdapURL or LdapUrl ? I'm fine with both, but I don't like LDAPURL OID: It's much more a ASN.1 notion, right. But in many case, we may manipulate an OID instead of a String. Frankly, the only thing I do with such a class right now is to use a static method named OID.isOid( String ). It can be left outside of the API too. CSN: Or EntryCSN. Not sure that it should be exposed too. > A data type that we have found particularly useful is AttributeDescription <snip/> If this is a wrapper on top of an AttributeType (or an ID), with options, then it sounds like a good idea. It could help having a lightweight API instead of having tens of methods for each specific case : AT with options, etc. > 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). We discussed a lot with Ludo about it. The Client API must not be schema aware, but it must allow someone to use a schema if needed. The default would be to use the core schema. In order to use the Schema within an entry, it would just be a matter of injecting the Schema into the Entry, either in the constructor, or later. It will of course propagate to all the included AT, Dn, etc... The details have to be explicited, of course > 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. Filter, +1 I'm not sure about the Matcher object, as it's supposed to be used by the server only. But who knows? > * Assertion - represents an attribute value assertion compiled by a > MatchingRule - typically these are stored in a compiled Filter > (Matcher) Same as above... > * Schema - a container of attribute types, object classes, etc We call it SchemaManager in ADS, Schema is definitively better. +1 > * 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. Again, a lot of discussion about it. I'm not convinced that we really need a ByteString object, as data are either String or byte[], and String will be internally converted to byte[] (after a PrepareString normalization). The AttributeValue is what I called AVA (sticking to the RFC terminology). It makes sense to me to have such an object, as we have to keep the user provided value, and to have a normalized form of this value. Of course, you can cach such a value in the Attribute, but you will have to do the same thing for the RDNs. I would arther discuss those specific points on another thread to not confuse people. > * Search scope (needs to be extensible - i.e. not an enum) So Scope or SearchScope ? Also, does it really have to be extensible ? > * Modification type (needs to be extensible - i.e. not an enum) Operation ? ModOp? > * Dereference aliases policy Sure. Don't have a name in mind > * Condition result for filters (true, false, undefined) Yup. A name ? -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
