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. > 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. WDYT? Kind Regards, Stefan
