directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject [ApacheDS] Separating normalization from parsing
Date Sun, 18 Sep 2005 18:40:12 GMT
Emmanuel, Ersin,

Emmanuel and I had a breif conversation on IRC regarding the 
inefficiencies caused by double parsing names at times to normalize 
them.  Emmanuel had a good yet simple idea to decouple these two 
operations so Name normalization did not require another parse. 

Incidentally this solution also solves another problem that Ersin and I 
had discussed.  Namely the need to be able to isolate normalization so 
that it is does not complicate parsing.  I just wanted to quickly let 
you Ersin know that Emmanuel had some thoughts on this. An let you 
Emmanuel know that Ersin was thinking about this stuff :-).

Emmanuel's solution involved producing a NameComponent for populating a 
Name rather than a String for the components.  This way the attribute 
type and value are separated into fields within NameComponent objects by 
a populating parser.  The normalization can then occur (it necessary) 
after the parse on the type and/or attribute value fields of the 
NameComponent objects within a DN.  This approach would allow 
normalization to be decoupled from parsing.

There is however a slight problem with this approach.   However I think 
we might be able to get around it.  Using a NameComponent instead of a 
String introduces a problem when mapping to the JNDI Name interface.  
Name expects a String for name components as seen by the add() methods, 
and the get() method.  Getting around this is easy.  The internal 
representation for name components can be a NameComponent object within 
LdapName rather than a String.  The add() methods can be overloaded to 
take a NameComponent in addition to a String.  The overloads taking a 
String can generate the NameComponent object before storing it within 
the internal array of NameComponents.  Similarly, the get() method can 
call toString() to return the String representation of the NameComponent 
(btw which can/should be cached by NameComponent).  A new 
getNameComponent() method can be added to LdapName for access to the 
individual name components by a normalizer.

I like Emmauel's approach very much and think it can lead to some 
serious optimizations within the server.

Thoughts? Comments?


View raw message