directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <aok...@bellsouth.net>
Subject Re: LdapDN impl into the server
Date Tue, 06 Jun 2006 13:45:55 GMT
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



Mime
View raw message