directory-api mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Radovan Semancik <radovan.seman...@evolveum.com>
Subject Re: Client API Schema support
Date Mon, 26 Jan 2015 12:38:22 GMT
On 01/26/2015 12:55 PM, Emmanuel L├ęcharny wrote:
> 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. 

Actually, I do not care at all about schema updates. That is too hard. 
And it is out of scope of loadSchema() operation anyway.

As long as loadSchema() works I'm happy.

> 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 
> cn=schema. 

No problem. I can do that.

>
> 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 would suggest not to use vendor data at all unless it is really 
necessary. These can change between product versions. This may be a 
difficult maintenance burden.
I would rather suggest this:

- get root DSE
- check vendor-specific data in root DSE for known special cases that 
fail with the "automagic" process below (hopefully not needed now, but 
we may need it in the future)
- try to use subschemasubentry from root DSE. If it works return the schema.
- if that fails, try going directly to cn=schema. If it works return the 
schema.
- if that fails, try X. If it works return the schema.
- if that fails, try Y. If it works return the schema.
- ...
- if all fails throw an error

Or, if there are issues we can modify it to something like:

- get root DSE
- check vendor-specific data in root DSE for known special cases that 
fail with the "automagic" process below (hopefully not needed now, but 
we may need it in the future)
- try to use subschemasubentry from root DSE.
    - try strict schema parser, If it works return the schema.
    - try more relaxed schema parser, If it works return the schema.
- if that fails, try going directly to cn=schema.
    - try strict schema parser, If it works return the schema.
    - try more relaxed schema parser, If it works return the schema.
- if that fails, try X. If it works return the schema.
- if that fails, try Y. If it works return the schema.
- ...
- if all fails throw an error

So, this will prefer servers that follow the standard way. Less 
roundtrips. But it should eventually find the schema for most servers in 
most cases without any configuration. And it is unlikely to break with 
new LDAP server versions and/or product rebranding as vendors tend to 
keep some form of backward compatibility.

This obviously needs some experimentation to get this right ... and I'm 
willing to do it.

BTW, I've just checked that at least OpenDJ and 389ds (and of course 
also OpenLDAP) all seems to support subschemasubentry in root DSE. And 
they all return the schema in what seems to be the RFC format. There may 
be some issues, of course. But it looks like that the support for these 
servers should not be difficult to implement.

-- 

                                            Radovan Semancik
                                           Software Architect
                                              evolveum.com


Mime
View raw message