On Wed, Feb 16, 2011 at 1:50 AM, Emmanuel Lecharny <[email protected]> wrote: > On 2/15/11 9:15 PM, Kiran Ayyagari wrote: >> >> On Wed, Feb 16, 2011 at 12:39 AM, Emmanuel Lecharny<[email protected]> >> wrote: >>> >>> On 2/15/11 8:00 PM, Kiran Ayyagari wrote: >>>> >>>> On Tue, Feb 15, 2011 at 8:53 PM, Emmanuel Lecharny<[email protected]> >>>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> the compareTo method has a semantic that probably does not applies to >>>>> the >>>>> Dn >>>>> class : either two DNs are equals, or they are different, but they >>>>> aren't >>>>> superior or inferior, except if one is the parent of the other. >>>>> >>>>> As we already have a isParent and isChild methods, I suggest we remove >>>>> the >>>>> compareTo() methods (which is never used) and not implemen the >>>>> Comparable<Dn> interface. >>>>> >>>> I suggest we keep this, think of ordering the Entry objects while >>>> performing an export >>>> (sorting a huge number of entries won't be the ideal case, but when we >>>> have a few entries which are fetched in an adhoc manner(i.e without >>>> performing repetitive one level searches)) >>> >>> The thing is that there is no way to order a list of DNs, as there is no >>> such a MatchingRule as DnOrderingMatch. How do you order two DNs which >>> RDN >>> don't have the same AttributeType ? >>> >>> I have checked RFC 4517, and after having read it, I saw that comparing >>> two >>> DNs is just meant to check that they are equal, or not. No order is >>> implied. >> >> how about using the isParent() and isChild() methods for that inside >> the compareTo() > > yes, but still it's not possible to compare 2 DNs with the same parent... > CompareTo() for DNs simply does not make sense :) hmmm, just wondering why can't we compare the normalized values(which are strings) of two DNs > > > -- > Regards, > Cordialement, > Emmanuel Lécharny > www.iktek.com > >
-- Kiran Ayyagari
