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