directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject Re: Some more thoughts about the Dn class
Date Thu, 17 Feb 2011 09:46:22 GMT
On 2/17/11 10:28 AM, Stefan Seelmann wrote:
> On Thu, Feb 17, 2011 at 9: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.
>>
>> 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]
>> * Dn.getAncestor( DNd ) ->  returns the DNa in [DNd][DNa]
>> * Dn.getDescendant( DNa ) ->  returns the DNd in [DNd][DNa]
> +1, please also add that definition to the Javadoc, this is a really
> nice, short, and clean description what the methods do.

Yes, sure, will do.
>> Is that ok ? Should we use something more clear, like
>> getAncestorOf/getDescendantOf ? Or use getAscendant/getDescendant ?
> I would prefer getAncestorOf/getDescendantOf.
>
> 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.

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 ?

-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com


Mime
View raw message