You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Alex Karasulu <ao...@bellsouth.net> on 2006/06/03 22:05:59 UTC

[LDAP] LdapDN questions part I

In the LdapDN doco you refer to it as a tree of RDNs:

 * It represents a tree, in which the root is the last RDN (RDN[0]) and the leaf
 * is the first RDN (RDN[n]).

Do you mean a list here?  Or am I missing something?

Alex



Re: LdapDN impl into the server

Posted by Alex Karasulu <ao...@bellsouth.net>.
Emmanuel Lecharny wrote:

> Alex,
>
> just a quick status before I hit the sack.
>
> Server is running again. Fixes where easy.
>
> 1) Atm, I have a clear problem when trying a search at the top level,
> with scope=ONE LEVEL : it returns everything.

Yeah I'll have to start debugging the scope based search constraints. 
It's not an easy peice of code.

>
> 2) I also have a problem with OID map: I need to get the <OID,
> Normalizer> couple, instead of <whatever alias, Normalizer> to store
> the OID into the normalized AttributeType of each RDN (as we will work
> with OID internally, not with alias). If we don't do that, we may have
> missed searches, I'm afraid. The method to modify is :
> org.apache.directory.shared.ldap.name.LdapDN.rdnOidToName() in
> shared-ldap.
> Here is the code (I've prepared a String oid variable to store the
> oid, currently, it stores the type)
>                    ...                                     // Should
> get the OID, not the type
>                    String oid = type;
>                   ...
> around line 1300

This is a big problem.  Currently the LdapDN class is rightfully in the
shared-ldap package.   To extract the OID of an attribute in the server
by attributeType alias we use the OidRegistry.  This however is a server
schema object in the core.  Naturally I'm sure you see why I don't want
to create a dependency here.

Perhaps I can give you another map.  An alias to OID map generated from
the OidRegistry. 

What do you think?

>
> 3) I think we should have two versions of codec : one for server, and
> one for client. The problem is that we do useless conversions when
> retruning results to the client. For instance, the SearchResultEntry
> will contain an objectName, and this should be a String, not a LdapDN,
> if we use it on the server side. Ok, I know, not a big deal... Let's
> keep this somwhere and put a little flag above it (a JIRA flag) and we
> will go back to it in july :)

I don't know if I agree on this.  But it is something to consider.   I
just don't have the brain power to contemplate this :(.

Alex



LdapDN impl into the server

Posted by Emmanuel Lecharny <el...@gmail.com>.
Alex,

just a quick status before I hit the sack.

Server is running again. Fixes where easy.

1) Atm, I have a clear problem when trying a search at the top level, 
with scope=ONE LEVEL : it returns everything. Search code is a little 
bit too complicated for my sleepy brain right now, but there is 
something I should have missed.

2) I also have a problem with OID map: I need to get the <OID, 
Normalizer> couple, instead of <whatever alias, Normalizer> to store the 
OID into the normalized AttributeType of each RDN (as we will work with 
OID internally, not with alias). If we don't do that, we may have missed 
searches, I'm afraid. The method to modify is : 
org.apache.directory.shared.ldap.name.LdapDN.rdnOidToName() in shared-ldap.
Here is the code (I've prepared a String oid variable to store the oid, 
currently, it stores the type)
                    ...                  
                    // Should get the OID, not the type
                    String oid = type;
                   ...
around line 1300

3) I think we should have two versions of codec : one for server, and 
one for client. The problem is that we do useless conversions when 
retruning results to the client. For instance, the SearchResultEntry 
will contain an objectName, and this should be a String, not a LdapDN, 
if we use it on the server side. Ok, I know, not a big deal... Let's 
keep this somwhere and put a little flag above it (a JIRA flag) and we 
will go back to it in july :)

ok, I'm dead now. Zzzzzzz....

Re: [LDAP] LdapDN questions part I

Posted by Alex Karasulu <ao...@bellsouth.net>.
Emmanuel Lecharny wrote:

> Alex Karasulu a écrit :
>
>> In the LdapDN doco you refer to it as a tree of RDNs:
>>
>> * It represents a tree, in which the root is the last RDN (RDN[0])
>> and the leaf
>> * is the first RDN (RDN[n]).
>>
>> Do you mean a list here?  Or am I missing something?
>>  
>>
> Yeah, it is a list, internally.
>
> The doco express the fact that a DN is seen as a branch of a tree,
> where each node is a RDN.
>
> Doco is not really acurate, and it should have been something like :
> "It represents a path through a tree, in which the root is the last
> RDN (RDN[0]) ..."
>
> To be clear, with a dn : dc=example, dc=org
> we have :
> RDN[0] : dc = org
> RDN[1] : dc=example

Gotchya no problem I figured but wanted to make sure.  I'm trying to
understand the semantics of using LdapDN first and what to look at it a
little more. 

Will ask more queswtions tomorrow.

Alex


Re: [LDAP] LdapDN questions part I

Posted by Emmanuel Lecharny <el...@gmail.com>.
Alex Karasulu a écrit :

>In the LdapDN doco you refer to it as a tree of RDNs:
>
> * It represents a tree, in which the root is the last RDN (RDN[0]) and the leaf
> * is the first RDN (RDN[n]).
>
>Do you mean a list here?  Or am I missing something?
>  
>
Yeah, it is a list, internally.

The doco express the fact that a DN is seen as a branch of a tree, where 
each node is a RDN.

Doco is not really acurate, and it should have been something like :
"It represents a path through a tree, in which the root is the last RDN 
(RDN[0]) ..."

To be clear, with a dn : dc=example, dc=org
we have :
RDN[0] : dc = org
RDN[1] : dc=example

Emmanuel.