directory-api mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <>
Subject Re: Client API Schema support
Date Mon, 26 Jan 2015 11:55:24 GMT
Le 26/01/15 12:04, Radovan Semancik a écrit :
> Hi,
> On 01/23/2015 09:07 PM, Emmanuel Lécharny wrote:
>> Thinking about it, as soon as the schema elements stored in the
>> subschemaSubentries are supposed to be standardized by RFC 4512, there
>> is no reason the existing code should not work with any server, except
>> that we should remove the
>> if ( isApacheDs( rootDse ) )
>> check...
>> Could you give that a try ?
> Yes, I will try this. However I guess it won't be that easy.
> Anyway, my thinking was probably similar to yours. I.e. we do not need
> to distinguish each server by its vendor name. We only need to support
> serveral well-know styles of representing schema. E.g. try looking for
> subschema entry in DSE. If that fails try going directly to cn=schema
> suffix (this seems to be the Netscape family style).

In ApacheDS, there are two ways you can update the schema :
- though the subschemaSubentry
- directly modifying the cn=schema partition.

In fact, updating one will update the other.

The only little difference (well, little is an understatement) is that
cn=schema has a proprietary format, when the DSE has a standard one.
This is why we do favor the DSE approach.

> Maybe try some other tricks. I guess that this is reasonably safe. It
> is unlikely that a non-schema entry will be mistakenly parsed as a
> schema entry. So it is pretty much OK to try (and fail) a lot of methods.

ATM, this approach sounds reasonable, indeed . I'm quite sure that it
would work with OpenLDAP, except that we have to change the code that
check if the remote server is ApacheDS. I can do that immediately.

If this approach does not fly for, say, server X, then we have to find a
way to know which kind of server it is, and then we can fail back to

> Also, getting the schema is already quite an expensive operation.
You bet... We can start with the root schema entry only, if it helps.

> Therefore adding several round-trips will not make it much worse than
> it already is. So I think this is the way to go. I guess that by
> implementing just a couple of these methods we can support majority of
> LDAP servers. And we do not even need to know their names.

At this point, the code will more or less looks like :

- check with RootDSE
- if it fails, try to get the server vender information
  - if we have some, read the schema using the appropriate method
  - otherwise, check cn=schema
    - for each server we support, try to read the schema, until we get
it read correctly

> I'll try it. My current list of servers to test is:
> OpenLDAP, OpenDJ, 389ds, eDirectory

I'll fix the API to get it easy for you to use OpenLDAP (ie, removing
the isApacheDS test).

Thanks !

View raw message