directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Re: Some more thoughts about the Dn class
Date Thu, 17 Feb 2011 10:11:42 GMT
On 2/17/11 11:07 AM, Stefan Seelmann wrote:
> On Thu, Feb 17, 2011 at 10:46 AM, Emmanuel Lecharny<>  wrote:
>> On 2/17/11 10:28 AM, Stefan Seelmann wrote:
>>> One concern: What is the use case of the getAncestorOf/getDescendantOf
>>> from the user's point of view? In the server and in studio such
>>> methods are useful (e.g. calculating the local name for ACI handling).
>>> But does the end user of the API really need those methods? I mean we
>>> should avoid to put methods into the Dn class that is only/mostly used
>>> in server and studio. Maybe a DnUtils class with static methods for
>>> advanced DN processing would help?
>> Good point. I can see some case where you need to split the DN in two parts,
>> for instance if you access two servers looking for an entry for which you
>> have the name. For instance, if you have two ldap server, one in US and one
>> in FR, you may have an entry present as "cn=John Doe, dc=acme, c=us" or
>> "cn=John Doe, dc=acme, c=fr", you may want to get the ancestor to know in
>> which server the entry is stored into.
> Hm, in that case you need to know the exact left-part (in that case
> "cn=John Doe, dc=acme") in order to call the getAnchestor() method,
> right? In that case a getAnchestor(1) would be more useful.

Yes, but we don't want to use the indexes for such operation, because 
users *never* now if the index is from the left or from the right. Add 
to that the fact that you also have to remember if it's a 0 based or 1 
based index ...
>> Know, we can also provide some helper class to do that, but I'm afraid users
>> will 'torture' the DN instead of using the DnUtils class, simply because hey
>> won't know that such a class exists.
>> Any opinion about the add() vs concatenate() methods ?
> What about getChild(), analog to getParent()?
>    Dn.getChild(String);
>    Dn.getChild(Dn);
>    Dn.getChild(Rdn);
> Ok, get methods normally don't required a parameter. So a
> createChild() would also be better.
getChild() is getRdn(). getChild( RDN) doesn't make a lot of sense, does 
it ?

Just to keep the semantic associated with the name, getRdn is closer to 
what the user might expect to use. May be getParent is not appropriate, 
we might want to use getBaseDn instead ?

Emmanuel L├ęcharny

View raw message