directory-api mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Seelmann <>
Subject Re: [DN] Existing API review
Date Wed, 13 Jan 2010 20:55:04 GMT
Matthew Swift wrote:
> On 12/01/10 14:29, Emmanuel Lecharny wrote:
> Even if you decide that caching is not required then that's no reason to 
> develop an API which prevents you from implementing one in future. Using 
> a normal constructor prevents the use of a cache (or forces you to use 
> the pimpl idiom). If you extend the API later by adding a valueOf method 
> then no existing applications will be able to take advantage of the perf 
> improvement unless they are modified to use the new static factory method.

Matthew, you mentioned good reasons for factory methdods. I think it is 
not a big deal to add a one or two factory methods.

>> The base constructor we can have are probably something like:
>> DN()
>> DN(String dnStr)
>> DN( RDN... rdns)
>> DN( RDN rdn, DN parent)

+1, and additional
   DN(DN localName, DN parent)

And let's add simple methods to get the parent of an DN. Every time I 
use JNDI I have to write a test to see the result of
   ldapName.getPrefix( ldapName.size() - 1 )

> Also, I strongly believe that DNs and RDNs and AVAs should be immutable 
> objects (as well as any other low level API type). What do you think?

Yes, I agree.

> Also, on the subject of AVAs - we have the AVA type as an inner class in 
> RDN. I'm not particularly happy with this this, but less happy with it 
> being a standalone class since AVAs are only used in RDNs and may 
> introduce confusion elsewhere. For example, filters also use attribute 
> value assertions but these are not the same type of object as an AVA 
> even if they have the same name. For example, AVAs (in RDNs) do not 
> allow attribute options or matching rules to be specified.
> What do you think? Inner class or standalone?

It could be an inner class, but should be visible and constructable from 
outside. The use case I see is to create an DN or RDN by specifying the 
attribute types and values, without having to deal with escaped 
characters. We need such functionality in Directory Studio, when 
defining the RDN of an entry or when renaming an entry. The user for 
example just types "a+b" into the value field, we construct a new 
AVA("cn", "a+b") and the AVA implementation should handle the escaping 
to "cn=a\+b".

Kind  Regards,

View raw message