On Thu, Feb 17, 2011 at 12:11 PM, Emmanuel Lecharny <[email protected]> wrote: > On 2/17/11 11:07 AM, Stefan Seelmann wrote: >> >> On Thu, Feb 17, 2011 at 10:46 AM, Emmanuel Lecharny<[email protected]> >> 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 ...
Yeah but unfortunately there are going to be times when you just need to slice and dice a DN without knowing it's contents. I'm afraid we're going to need something along this line. Alex
