directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <elecha...@gmail.com>
Subject Dn, Rdn and Ava inconstancies
Date Mon, 20 Feb 2012 16:33:36 GMT
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=Doe+gn=John does not work when 
searching for gn=John+cn=Doe
- 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=exemple \+ rdn\C3\A4\ "
     getNormType()    “ou”
     getNormValue()    "exemple + rdnä "
     getUpName()    "OU = Exemple \+ Rdn\C3\A4\ "
     getUpType()    “OU“
     getUpValue()    "Exemple + Rdnä "
     normalize()    "ou=exemple \+ rdn\C3\A4\ "
     toString()    "OU = Exemple \+ Rdn\C3\A4\ "

and if the AVA is schema aware :

     getNormName() “2.5.4.11=example \+ rdn\C3\A4\ ”
     getNormType() “2.4.5.11”
     getNormValue() “exemple + rdnä ”
     getUpName() "OU = Exemple \+ Rdn\C3\A4\ "
     getUpType() “OU“
     getUpValue() "Exemple + Rdnä "
     normalize() “2.5.4.11=example \+ rdn\C3\A4\ ”
     toString() "OU = Exemple \+ Rdn\C3\A4\ "

Currently, this is not what we get :

     Ava.getNormName() returns 'ou=Exemple \\\+ Rdn\\C3\\A4\\\ '
     Ava.getUpValue() returns 'Exemple \+ Rdn\C3\A4\ '
     Ava.normalize() returns 'ou=Exemple \\\+ 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 = Exemple \+ Rdn\C3\A4\ +cn=  TEST"
     getNormName()    "ou=exemple \+ rdn\C3\A4\ "
     getNormType()    "ou"
     getNormValue()    "exemple + rdnä "
     getUpType()    “OU“
     getUpValue()    "Exemple \+ Rdn\C3\A4\ "
     getValue(String)    "Exemple \+ Rdn\C3\A4\ " and “TEST”
     toString()    "OU = Exemple \+ Rdn\C3\A4\ +cn=  TEST"

and if the RDN is schema aware :

     getName()    "OU = Exemple \+ Rdn\C3\A4\ +cn=  TEST"
     getNormName()    “2.5.4.11=example \+ rdn\C3\A4\ ”
     getNormType()    "2.5.4.3"
     getNormValue()    “exemple + rdnä “
     getUpType()    “OU“
     getUpValue()    "Exemple \+ Rdn\C3\A4\ “
     getValue(String)    "Exemple \+ Rdn\C3\A4\ " and “TEST”
     toString()    "OU = Exemple \+ Rdn\C3\A4\ +cn=  TEST"

This is what we get :

Rdn.getNormName() returns 'ou=Exemple \+ Rdnä\ +cn=TEST'
Rdn.getNormValue() returns 'Exemple + Rdnä '
Rdn.getUpValue() returns ' Exemple \+ Rdn\C3\A4\ '
Rdn.getValue( 'ou' ) returns 'Exemple + Rdnä '
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 
same analysis 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 errors when they appear. I think it's time to play medieval 
on the code !

Thoughts ?

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


Mime
View raw message