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 11:04:48 GMT
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). 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. Also, getting the 
schema is already quite an expensive operation. 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.

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

So I'm going to play with these during next couple of weeks. And we can 
try other servers later on.

-- 

                                            Radovan Semancik
                                           Software Architect
                                              evolveum.com


Mime
View raw message