Return-Path: X-Original-To: apmail-directory-dev-archive@www.apache.org Delivered-To: apmail-directory-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 127549B60 for ; Mon, 20 Feb 2012 18:36:40 +0000 (UTC) Received: (qmail 42647 invoked by uid 500); 20 Feb 2012 18:36:39 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 42599 invoked by uid 500); 20 Feb 2012 18:36:39 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 42587 invoked by uid 99); 20 Feb 2012 18:36:39 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 20 Feb 2012 18:36:39 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of akarasulu@gmail.com designates 74.125.82.178 as permitted sender) Received: from [74.125.82.178] (HELO mail-we0-f178.google.com) (74.125.82.178) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 20 Feb 2012 18:36:31 +0000 Received: by werb12 with SMTP id b12so4570422wer.37 for ; Mon, 20 Feb 2012 10:36:11 -0800 (PST) Received-SPF: pass (google.com: domain of akarasulu@gmail.com designates 10.180.14.193 as permitted sender) client-ip=10.180.14.193; Authentication-Results: mr.google.com; spf=pass (google.com: domain of akarasulu@gmail.com designates 10.180.14.193 as permitted sender) smtp.mail=akarasulu@gmail.com; dkim=pass header.i=akarasulu@gmail.com Received: from mr.google.com ([10.180.14.193]) by 10.180.14.193 with SMTP id r1mr20495308wic.9.1329762971434 (num_hops = 1); Mon, 20 Feb 2012 10:36:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=A4xC8e2KK2Im8HZ5zF9IuOgUSidB91FUlRK6j/cyfww=; b=n5pFKwnZjn/JI2Lwvv2YcVuurW5l3t38MITVkMNQSypX7cAEtmqET/uwW78GPH+LHm VZ/amEVx1BsysIrPiK+5cxLCk3bPCTYa8apCEz5QZU2xHNtd4oW8lzmSdVOEWqvPh4HJ mBvCulXm4/d+UrYqo0xRoypwyMWPUKMuyZyS0= MIME-Version: 1.0 Received: by 10.180.14.193 with SMTP id r1mr17104878wic.9.1329762971356; Mon, 20 Feb 2012 10:36:11 -0800 (PST) Sender: akarasulu@gmail.com Received: by 10.180.93.132 with HTTP; Mon, 20 Feb 2012 10:36:11 -0800 (PST) In-Reply-To: <4F4275E0.9050207@gmail.com> References: <4F4275E0.9050207@gmail.com> Date: Mon, 20 Feb 2012 20:36:11 +0200 X-Google-Sender-Auth: ERf7FFl0JO2pQ0KWF0uqYXRhoWw Message-ID: Subject: Re: Dn, Rdn and Ava inconstancies From: Alex Karasulu To: Apache Directory Developers List , elecharny@apache.org Content-Type: multipart/alternative; boundary=f46d04138a9d8b0c9504b9699118 X-Virus-Checked: Checked by ClamAV on apache.org --f46d04138a9d8b0c9504b9699118 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Mon, Feb 20, 2012 at 6:33 PM, Emmanuel L=E9charny w= rote: > Hi guys, > > those last days, we had to fight with some issues with the way we handle > DNs and its components : > - creating entries with a RDN containing two times the same AT is not > allowed by the spec > - searching for an entry which RDN is cn=3DDoe+gn=3DJohn does not work wh= en > searching for gn=3DJohn+cn=3DDoe > - renaming an entry on itself when we want to upercase a RDN is not > possible when it should. > > Digging a bit into the code, I found that many cases weren't handled > correctly, and the the API is not consistant. We also have issues with > escaped characters. > > For instance, if we consider the Ava class, there are some methods that > need to be renamed : > o getUpName() should be renamed to getName() as Dn.getName() and > Rdn.getName() are used > o getUpType() should be renamed to getType() to be consistant with the > previous rename > o getUpValue() should also be renamed to getValue() for the very same > reason. > > Now, when it comes to what the methods produce, here is a table showing > the expected values : > > If the AVA is not schema aware : > > getNormName() "ou=3Dexemple \+ rdn\C3\A4\ " > getNormType() =93ou=94 > getNormValue() "exemple + rdn=E4 " > getUpName() "OU =3D Exemple \+ Rdn\C3\A4\ " > getUpType() =93OU=93 > getUpValue() "Exemple + Rdn=E4 " > normalize() "ou=3Dexemple \+ rdn\C3\A4\ " > toString() "OU =3D Exemple \+ Rdn\C3\A4\ " > > and if the AVA is schema aware : > > getNormName() =932.5.4.11=3Dexample \+ rdn\C3\A4\ =94 > getNormType() =932.4.5.11=94 > getNormValue() =93exemple + rdn=E4 =94 > getUpName() "OU =3D Exemple \+ Rdn\C3\A4\ " > getUpType() =93OU=93 > getUpValue() "Exemple + Rdn=E4 " > normalize() =932.5.4.11=3Dexample \+ rdn\C3\A4\ =94 > toString() "OU =3D Exemple \+ Rdn\C3\A4\ " > > Currently, this is not what we get : > > Ava.getNormName() returns 'ou=3DExemple \\\+ Rdn\\C3\\A4\\\ ' > Ava.getUpValue() returns 'Exemple \+ Rdn\C3\A4\ ' > Ava.normalize() returns 'ou=3DExemple \\\+ Rdn\\C3\\A4\\\ ' > > The normalize() method seems useless. > > > For RDN, we also have some method renaming to anticipate : > o getUpType() should be renamed getType() > o getUpValue() should be renamed getValue() > o getValue(String) should be removed, we can grab the value using the > getAva( String ) instead > > Same, for the expected values and the values we get : > > getName() "OU =3D Exemple \+ Rdn\C3\A4\ +cn=3D TEST" > getNormName() "ou=3Dexemple \+ rdn\C3\A4\ " > getNormType() "ou" > getNormValue() "exemple + rdn=E4 " > getUpType() =93OU=93 > getUpValue() "Exemple \+ Rdn\C3\A4\ " > getValue(String) "Exemple \+ Rdn\C3\A4\ " and =93TEST=94 > toString() "OU =3D Exemple \+ Rdn\C3\A4\ +cn=3D TEST" > > and if the RDN is schema aware : > > getName() "OU =3D Exemple \+ Rdn\C3\A4\ +cn=3D TEST" > getNormName() =932.5.4.11=3Dexample \+ rdn\C3\A4\ =94 > getNormType() "2.5.4.3" > getNormValue() =93exemple + rdn=E4 =93 > getUpType() =93OU=93 > getUpValue() "Exemple \+ Rdn\C3\A4\ =93 > getValue(String) "Exemple \+ Rdn\C3\A4\ " and =93TEST=94 > toString() "OU =3D Exemple \+ Rdn\C3\A4\ +cn=3D TEST" > > This is what we get : > > Rdn.getNormName() returns 'ou=3DExemple \+ Rdn=E4\ +cn=3DTEST' > Rdn.getNormValue() returns 'Exemple + Rdn=E4 ' > Rdn.getUpValue() returns ' Exemple \+ Rdn\C3\A4\ ' > Rdn.getValue( 'ou' ) returns 'Exemple + Rdn=E4 ' > Rdn.getValue( 'test' ) returns '' > > Etc... > > I have not yet coded the tests for the schema aware AVA and RDN, but be > sure we will get more inconsistencies. I still have to write down the sam= e > analysis for Dn, but this is the same story. > > > We really need to fix those inconsistencies otherwise we will have endles= s > issues. This is not the first time we are dealing with them, bt so far, w= e > never had to face them for real, and we just tried our best to shoot the > errors when they appear. I think it's time to play medieval on the code ! > This makes a lot of sense. As things matured in the project we started seeing more and more of the corner cases that we need to account for. As you say, we did this incrementally as we encountered various situations. Over time this strains how this area of the library was designed. Naturally you cannot account for everything and over time various choices see obsolete as you patch and patch and patch the code. Now after seeing so much of the corner cases and how the design may not be supporting it cleanly, and efficiently, then sure re-architect it know that we have the tests, history and the knowledge. -- My 2 cents, -- Alex --f46d04138a9d8b0c9504b9699118 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On Mon, Feb 20, 2012 at 6:33 PM, Emmanue= l L=E9charny <e= lecharny@gmail.com> wrote:
Hi guys,

those last days, we had to fight with some issues with the way we handle DN= s and its components :
- creating entries with a RDN containing two times the same AT is not allow= ed by the spec
- searching for an entry which RDN is cn=3DDoe+gn=3DJohn does not work when= searching for gn=3DJohn+cn=3DDoe
- renaming an entry on itself when we want to upercase a RDN is not possibl= e when it should.

Digging a bit into the code, I found that many cases weren't handled co= rrectly, and the the API is not consistant. We also have issues with escape= d characters.

For instance, if we consider the Ava class, there are some methods that nee= d to be renamed :
o getUpName() should be renamed to getName() as Dn.getName() and Rdn.getNam= e() are used
o getUpType() should be renamed to getType() to be consistant with the prev= ious rename
o getUpValue() should also be renamed to getValue() for the very same reaso= n.

Now, when it comes to what the methods produce, here is a table showing the= expected values :

If the AVA is not schema aware :

=A0 =A0getNormName() =A0 =A0"ou=3Dexemple \+ rdn\C3\A4\ "
=A0 =A0getNormType() =A0 =A0=93ou=94
=A0 =A0getNormValue() =A0 =A0"exemple + rdn=E4 "
=A0 =A0getUpName() =A0 =A0"OU =3D Exemple \+ Rdn\C3\A4\ "
=A0 =A0getUpType() =A0 =A0=93OU=93
=A0 =A0getUpValue() =A0 =A0"Exemple + Rdn=E4 "
=A0 =A0normalize() =A0 =A0"ou=3Dexemple \+ rdn\C3\A4\ "
=A0 =A0toString() =A0 =A0"OU =3D Exemple \+ Rdn\C3\A4\ "

and if the AVA is schema aware :

=A0 =A0getNormName() =932.5.4.11=3Dexample \+ rdn\C3\A4\ =94
=A0 =A0getNormType() =932.4.5.11=94
=A0 =A0getNormValue() =93exemple + rdn=E4 =94
=A0 =A0getUpName() "OU =3D Exemple \+ Rdn\C3\A4\ "
=A0 =A0getUpType() =93OU=93
=A0 =A0getUpValue() "Exemple + Rdn=E4 "
=A0 =A0normalize() =932.5.4.11=3Dexample \+ rdn\C3\A4\ =94
=A0 =A0toString() "OU =3D Exemple \+ Rdn\C3\A4\ "

Currently, this is not what we get :

=A0 =A0Ava.getNormName() returns 'ou=3DExemple \\\+ Rdn\\C3\\A4\\\ = 9;
=A0 =A0Ava.getUpValue() returns 'Exemple \+ Rdn\C3\A4\ '
=A0 =A0Ava.normalize() returns 'ou=3DExemple \\\+ Rdn\\C3\\A4\\\ '=

The normalize() method seems useless.


For RDN, we also have some method renaming to anticipate :
o getUpType() should be renamed getType()
o getUpValue() should be renamed getValue()
o getValue(String) should be removed, we can grab the value using the getAv= a( String ) instead

Same, for the expected values and the values we get :

=A0 =A0getName() =A0 =A0"OU =3D Exemple \+ Rdn\C3\A4\ +cn=3D =A0TEST&= quot;
=A0 =A0getNormName() =A0 =A0"ou=3Dexemple \+ rdn\C3\A4\ "
=A0 =A0getNormType() =A0 =A0"ou"
=A0 =A0getNormValue() =A0 =A0"exemple + rdn=E4 "
=A0 =A0getUpType() =A0 =A0=93OU=93
=A0 =A0getUpValue() =A0 =A0"Exemple \+ Rdn\C3\A4\ "
=A0 =A0getValue(String) =A0 =A0"Exemple \+ Rdn\C3\A4\ " and =93T= EST=94
=A0 =A0toString() =A0 =A0"OU =3D Exemple \+ Rdn\C3\A4\ +cn=3D =A0TEST= "

and if the RDN is schema aware :

=A0 =A0getName() =A0 =A0"OU =3D Exemple \+ Rdn\C3\A4\ +cn=3D =A0TEST&= quot;
=A0 =A0getNormName() =A0 =A0=932.5.4.11=3Dexample \+ rdn\C3\A4\ =94
=A0 =A0getNormType() =A0 =A0"2.5.4.3"
=A0 =A0getNormValue() =A0 =A0=93exemple + rdn=E4 =93
=A0 =A0getUpType() =A0 =A0=93OU=93
=A0 =A0getUpValue() =A0 =A0"Exemple \+ Rdn\C3\A4\ =93
=A0 =A0getValue(String) =A0 =A0"Exemple \+ Rdn\C3\A4\ " and =93T= EST=94
=A0 =A0toString() =A0 =A0"OU =3D Exemple \+ Rdn\C3\A4\ +cn=3D =A0TEST= "

This is what we get :

Rdn.getNormName() returns 'ou=3DExemple \+ Rdn=E4\ +cn=3DTEST'
Rdn.getNormValue() returns 'Exemple + Rdn=E4 '
Rdn.getUpValue() returns ' Exemple \+ Rdn\C3\A4\ '
Rdn.getValue( 'ou' ) returns 'Exemple + Rdn=E4 '
Rdn.getValue( 'test' ) returns ''

Etc...

I have not yet coded the tests for the schema aware AVA and RDN, but be sur= e we will get more inconsistencies. I still have to write down the same ana= lysis for Dn, but this is the same story.


We really need to fix those inconsistencies otherwise we will have endless = issues. This is not the first time we are dealing with them, bt so far, we = never had to face them for real, and we just tried our best to shoot the er= rors when they appear. I think it's time to play medieval on the code !=

This makes a lot of sense. As things matur= ed in the project we started seeing more and more of the corner cases that = we need to account for. =A0As you say, we did this incrementally as we enco= untered various situations.

Over time this strains how this area of the library wa= s designed. Naturally you cannot account for everything and over time vario= us choices see obsolete as you patch and patch and patch the code.=A0

Now after seeing so much of the corner cases and how the des= ign may not be supporting it cleanly, and efficiently, then sure re-archite= ct it know that we have the tests, history and the knowledge.

--
My 2 cents,
-- Alex

--f46d04138a9d8b0c9504b9699118--