directory-api mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@apache.org>
Subject Re: Let's start for real ?
Date Fri, 27 Nov 2009 11:42:27 GMT
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

Mime
View raw message