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:07:14 GMT
On Thu, Feb 17, 2011 at 10:37 AM, Emmanuel Lécharny
<elecharny@apache.org> wrote:
> On 2/17/11 12:43 AM, Alex Karasulu wrote:
>>
>> On Thu, Feb 17, 2011 at 1:20 AM, Emmanuel Lécharny<elecharny@apache.org>
>>  wrote:
>>>
>>> On 2/17/11 12:03 AM, Alex Karasulu wrote:
>>>>
>>>> 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() ?
>>>>
>>>> Because the result is not necessarily the parent of 'dn'. It may be if
>>>> it's immediately superior. You're mixing together the meanings I
>>>> think.
>>>
>>> Sorry, I don't get it. You have a DN, and you want the parent of it's
>>> left
>>> part, how possible the result couldn't be the parent ? If the parameter
>>> is
>>> not the left part, then you get an exception, but that's in the contract.
>>>
>>> Did I missed something ?
>>
>> The dn is “9, 8, 7, 6, 5, 4, 3, 2, 1, 0” you're getting one of it's
>> ancestors not it's parent.
>>
>> The parent would be “8, 7, 6, 5, 4, 3, 2, 1, 0”, the ancestor in the
>> example is “5, 4, 3, 2, 1, 0”.
>>
>> You see what I mean?
>> Alex
>>
> Bottom line, it does not really matter... What is important is that we agree
> on a name that express what the operation does.

It does matter even if its a very subtle difference. You're trying to
convey meaning avoiding ambiguity. Ancestor and parent have different
meanings and we're just trying to use them correctly in our API.

> So, considering that a DN can be expressed either as [RDN][DNp] or
> [DNd][DNa] with DNp = parent, DNa = ancestor, DNd = descendant (DNp and DNa
> are equivalent, it's just that a DNa may have a DNd, when a DNp can only ave
> a RDN) :
> * Dn.getParent() -> returns the DNp in [RDN][DNp]

I agree with this. I think this is the correct usage of parent. It's
the immediate ancestor.

> * Dn.getAncestor( DNd ) -> returns the DNa in [DNd][DNa]

+1

> * Dn.getDescendant( DNa ) -> returns the DNd in [DNd][DNa]

+1

> Is that ok ?

Just perfect. I think we were thinking the same thing all along. The
problem was expressing this.

Should we use something more clear, like
> getAncestorOf/getDescendantOf ? Or use getAscendant/getDescendant ?

Yeah getAncestorOf/getDescendantOf sounds like it flows better and
clarifies that we're taking this from the dn the operation is applied
to.

Regards,
Alex

Mime
View raw message