directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ersin Er <ersin...@gmail.com>
Subject Re: DnParser
Date Wed, 19 Oct 2005 06:59:06 GMT
I think it's better to redefine LdapName as Sun did in 5.0 and
normalization should be a seperate process. (Emmanuel, I favor my
previous proposal.) This will also provide compatitibility with Java
SE for future versions of ApacheDS.

See: http://java.sun.com/j2se/1.5.0/docs/api/javax/naming/ldap/LdapName.html

On 10/19/05, Emmanuel Lecharny <elecharny@apache.org> wrote:
> <snip/>
> > >8.1 :
> > >...
> > >When performing the caseIgnoreMatch, caseIgnoreListMatch,
> > >   telephoneNumberMatch, caseExactIA5Match and caseIgnoreIA5Match,
> > >   *multiple adjoining whitespace characters are treated the same as an*
> > >*   individual space*, and leading and trailing whitespace is ignored.
> > >
> > >
> > That was a good description of why this is the case.
> >
> > Alex
>
> At a point, we may want to have a DnParser, and a DnNormalizer. The
> DnParser will just check that the DN is correct, and the DnNormalizer
> will use the Schema to transform the NameComponents.
>
> It's not obvious that the normalization should occur during the parsing.
> I don't know if just a question of separation of concern, or of
> performance is improved by this three phases process (I don't think so),
> but the fact is that we should go through those three phases :
>
> 1) String -> nameComponents
> 2) nameComponents -> normalized nameComponents
> 3) normalized nameComponents -> normalized String
>
> What is the best solution?
>
> wdyt ?
>
> >
> > ---------------------------------------------------------------------------------------
> > Wanadoo vous informe que cet  e-mail a ete controle par l'anti-virus mail.
> > Aucun virus connu a ce jour par nos services n'a ete detecte.
> >
> >
> >
>
>
>
>


--
Ersin
Mime
View raw message