directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <akaras...@apache.org>
Subject Re: Some more thoughts about the Dn class
Date Thu, 17 Feb 2011 11:25:25 GMT
On Thu, Feb 17, 2011 at 12:55 AM, Emmanuel Lécharny
<elecharny@apache.org> wrote:
> On 2/16/11 9:02 PM, Alex Karasulu wrote:
>>
>> On Wed, Feb 16, 2011 at 4:50 PM, Emmanuel Lecharny<elecharny@gmail.com>
>>  wrote:
>>>
>>> Hi,
>>>
>>> we have had some convo about the Dn methods last night. Here are some of
>>> the things we discussed and came with :
>>>
>>> o the getPrefix(N)/getSuffix(N) are cumbersome, and not easy to
>>> manipulate. The main issue is that they depend on the RDN order, which is
>>> the opposite as what people are used to manipulate. Everytime you have to
>>> get a prefix from a Dn, you always wonder what the position should be, and
>>> if it's 0 based or 1 based...
>>>
>>> We propose to replace those methods by getParent(Dn) and
>>> getDescendant(Dn). Let me give you an example :
>>>
>>> // A DN
>>> Dn dn = new Dn( "cn=test,ou=server,ou=directory,dc=apache,dc=org" );
>>>
>>> // Get the right part (equivalent to getprefix( 2 ) )
>>> Dn parent = dn.getParent( "cn=test,ou=server,ou=directory" ); // returns
>>> "dc=apache,dc=org"
>>>
>>> // Get the left part (equivalent to getSuffix( 3 ))
>>> Dn descendant = dn.getDescendant( "ou=directory,dc=apache,dc=org" ); //
>>> returns "cn=test,ou=server"
>>>
>>> o The Add method is a bit annoying to remove, because first, the JNDI
>>> Name interface has such a method, and people are used to it, second removing
>>> it means we have to add some more constructors line Dn( Dn, Rdn... ). I
>>> agree that someone doing something like :
>>>
>>> Dn dn = new Dn( "dc=apache,dc=org" );
>>> dn.add( "ou=directory" );
>>>
>>> will expect that the dn is now "ou=directory,dc=apache,dc=org", when it's
>>> unchanged.
>>>
>>> This is really troublesome... What about rename it concatenate() ?
>>>
>>> Thoughts ?
>>
>> Sounds good. But how about this:
>>
>> // not showing full Rdn but an index value representing the actual
>> rdns in the dn for pos clarity
>> Dn dn = new Dn( “9, 8, 7, 6, 5, 4, 3, 2, 1, 0” );
>>
>> dn.getAncestorDn( “9, 8, 7, 6” );
>>
>> =>  “5, 4, 3, 2, 1, 0”
>
> That's ok, but why not getParent() ? getAncestorDn() is loooong. I'd rather
> use getAncestor(), but I find it more user friendly to use getParent()

In the end, getAncestorOf() is just as long as getAncestorDn() and
this is the conclusion we came to in previous posts.

Generally shorter is better I do agree with you 100%. However we're in
a sticky area here where it's not so easy to describe the method with
a single English word. So we're going to have to compromise a little
for the sake of clarity.

>> dn.getDnToAncestor( “1, 0” );
>
> Again, the name is frankly difficult to understand, and also confusing
> (getDnToAncestor ? getAncestorDn ? Which one does what ?).

The reason why I rearranged this from getDescendantOf() which I do
prefer myself is because of a key difference in the returned Dn. It's
a path difference. The getAncestorOf returns something from the root
of the original Dn being operated on like so:

>> Dn dn = new Dn( “9, 8, 7, 6, 5, 4, 3, 2, 1, 0” );
>>
>> dn.getAncestorDn( “9, 8, 7, 6” );
>>
>> =>  “5, 4, 3, 2, 1, 0”

But getDescendantOf( "1, 0" ) returns a relative path from the leaf up
to the referenced node:

“9, 8, 7, 6, 5, 4, 3, 2"

Without context we cannot be certain if the original Dn was an
absolute path from the root. However what we do know is that
getDescendantOf always returns a relative path from the leaf node up
to some ancestor. Hence why I tried to express this in the identifier
for the method getDnToAncestor().

getDnToAncestor connotates getting a Dn from somewhere below an
ancestor up to that ancestor but not all the way to the root. So it's
clear that we're dealing with a relative Dn for sure.

What's irritating me is that getAncestorOf() returns a Dn which shares
a common lineage with the dn operated on. If the original Dn is
absolute we know that getAncestorOf returns an absolute Dn. But
getDescendantOf is not the same, it always returns a relative Dn.

So these two operations are not very symmetric when it comes to what
they return. If getDescendantOf was returning an absolute Dn to a
descendant of an ancestor that's a different case.

So I have a problem with hinting symmetry here with getAncestorOf and
getDescendantOf because it can be potentially misleading. I'd rather
choose an identifier that clearly shows that a subpath is returned
instead of using getDescendantOf. The best I could come up with was
getDnToAncestor.

Regards,
Alex

Mime
View raw message