directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Re: DN parsng wiki page
Date Mon, 14 Jul 2008 23:58:07 GMT
Hi guys,

thanks for your comments on this very preliminary page. More inline.

Alex Karasulu wrote:
> On Mon, Jul 14, 2008 at 2:51 PM, Howard Chu <> wrote:
>> Ah, looks like a quite familiar pain. Just a note, in X.500/LDAP docs what
>> you called an ATAV is known as an AVA. Might want to line up the terminology
>> to make the correspondence clearer.
> +1
Will switch to AVA, sure.
>> And may I suggest another optimization to consider - for your AttributeType
>> internal structure, store a reference to the schema element, not a
>> normalized OID.
> I think this is a good idea and something we've debated.  Our problem comes
> from the fact that this LdapDN class and it's LdapDNParser is way
> overloaded.  We keep making some things serve more than one use.  Namely
> referring to the fact that these classes are designed to work in clients and
> servers : hence the reason for sticking to an OID.  Not all clients are
> going to want to waste the time to perform a search over schema subentry
> attributes to resolve, parse and generate the AT representation.
There is a reason why the LdapDN was not using AttributeType ( our 
internal 'pointer' to the schema ), it's that the DN are parsed during 
the LDAP protocol decoding. When it was first done, we didn't had easy 
access to the schema objects. This was debated from the begining (should 
we parse the DN while decoding the PDUs or not), and I'm not really sure 
I was right to push this idea. May be it's better to parse the DN later 
(but then, when ? The problem is that we need the DN pretty early, even 
before passing through the normalization Interceptor.)

Anyway, the idea here is to put everything on the table, and start to 
think again with some open mind.

Second point, raised by Alex, the fact we have a client/server mixed DN 
object may be over killing, and a separation would be good to have. 
Currently, this is done through a call to a Normalize method, which is 
not the best way to do it, because we also have to do the prepString 
before, and also because the client DN does not need this method.
> My mindset on these matters is very RISC+UNIX'ish in their nature.  Write
> something that does only one thing and does it well, simpley, in a managable
> and efficient manner.  That's why I think we need to break up this LdapDN
> into ClientDn and ServerDn.  You can add the LDAP part to these names but
> I'm not worried about the naming right now: just that we need to break these
> suckers up.
+1. I will start thinking about it. LdapDN and ServerDN sounds good to me.

Another idea we have had would be to write a very fast DN parser which 
assumes that a DN is composed of ASCII chars, with a single AVA per RDN, 
without any special chars like " or +. If we fall into a special case, 
an exeption will be thrown and we fall back into the complex DN parser. 
this may save us a lot of CPU cycles...
> We're paying for an overhead in complexity and performance because we're
> trying to generalize one implementation to solve two different ways of
> dealing with handling LDAP distinguished names.
I'm not sure that we are paying a huge penalty in term of performance, 
but in term of complexity and maintainability, it just sucks ... Even 
for me ;)
>> You're going to need to dereference fields of the schema definition
>> frequently when dealing with it anyway,
> Yeah big time.
>> e.g. to find the syntax and what normalization rules it uses. And, whether
>> you take this approach or not, you need a strategy for dealing with
>> unrecognized attributeTypes. I.e., right now you're using the OID, but what
>> happens if you're unable to find the OID?
> Another excellent point.
Currently, if the OID is not found, then we consider that the DN is 
incorrect, and we throw an error. This is done during the DN 
normalization. Is that the correct behavior ? (Assuming that we handle 
correctly the referrals and extensible ObjectClass... To be double 
checked ! Did I forgot any other case ?)
>> Presumably the schema is always resident in memory, and a reference will be
>> the most memory efficient...
> +1 for the server dn and it's parser.
> Thanks for chiming in Howard.  It's always good to have your input!
Damn yes !

More to come on the DN parsing page. I have 4 hours in the train 
tomorrow, perfect time to write doco.

Thanks guys  !

cordialement, regards,
Emmanuel L├ęcharny

View raw message