Mailing-List: contact api-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: api@directory.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Message-ID: <54C61F50.7010800@evolveum.com>
Date: Mon, 26 Jan 2015 12:04:48 +0100
From: Radovan Semancik <radovan.semancik@evolveum.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: api@directory.apache.org
Subject: Re: Client API Schema support
References: <54C10D22.2070800@evolveum.com> <54C11D84.1020404@gmail.com>
 <54C12D66.7050300@evolveum.com> <54C132F8.3000306@gmail.com>
 <54C26069.4030704@gmail.com> <54C2A9FA.4020805@gmail.com>
In-Reply-To: <54C2A9FA.4020805@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Hi,

On 01/23/2015 09:07 PM, Emmanuel L=C3=A9charny 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=20
to distinguish each server by its vendor name. We only need to support=20
serveral well-know styles of representing schema. E.g. try looking for=20
subschema entry in DSE. If that fails try going directly to cn=3Dschema=20
suffix (this seems to be the Netscape family style). Maybe try some=20
other tricks. I guess that this is reasonably safe. It is unlikely that=20
a non-schema entry will be mistakenly parsed as a schema entry. So it is=20
pretty much OK to try (and fail) a lot of methods. Also, getting the=20
schema is already quite an expensive operation. Therefore adding several=20
round-trips will not make it much worse than it already is. So I think=20
this is the way to go. I guess that by implementing just a couple of=20
these methods we can support majority of LDAP servers. And we do not=20
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=20
try other servers later on.

--=20

                                            Radovan Semancik
                                           Software Architect
                                              evolveum.com