directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <akaras...@apache.org>
Subject Re: DN parsng wiki page
Date Mon, 14 Jul 2008 21:30:58 GMT
On Mon, Jul 14, 2008 at 2:51 PM, Howard Chu <hyc@symas.com> wrote:

> Alex Karasulu wrote:
>
>> Wow this page is pretty good.  Nice doco!
>>
>
> 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


>
> 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.

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.

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.


> 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.


>
> 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!

Alex

Alex


>
>
>> Alex
>>
>> On Mon, Jul 14, 2008 at 5:42 AM, Emmanuel Lecharny <elecharny@gmail.com
>> <mailto:elecharny@gmail.com>> wrote:
>>
>>    Hi,
>>
>>    I started a page on wiki about the DN parsing process.
>>    http://cwiki.apache.org/confluence/display/DIRxSRVx11/DN+Parsing
>>
>>    The idea is to describe what we should do to parse a DN in the most
>>    efficient way, but keeping it maintainable at the same time.
>>
>>    I will try to complete it this week.
>>
>>    --
>>    --
>>    cordialement, regards,
>>    Emmanuel L├ęcharny
>>    www.iktek.com <http://www.iktek.com>
>>    directory.apache.org <http://directory.apache.org>
>>
>>
>>
>>
>>
>> --
>> Microsoft gives you Windows, Linux gives you the whole house ...
>>
>
>
> --
>  -- Howard Chu
>  CTO, Symas Corp.           http://www.symas.com
>  Director, Highland Sun     http://highlandsun.com/hyc/
>  Chief Architect, OpenLDAP  http://www.openldap.org/project/
>



-- 
Microsoft gives you Windows, Linux gives you the whole house ...

Mime
View raw message