Mailing-List: contact api-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: api@directory.apache.org
Received-SPF: pass (athena.apache.org: domain of elecharny@gmail.com
 designates 74.125.82.52 as permitted sender)
Message-ID: <54C132F8.3000306@gmail.com>
Date: Thu, 22 Jan 2015 18:27:20 +0100
From: =?UTF-8?B?RW1tYW51ZWwgTMOpY2hhcm55?= <elecharny@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9;
 rv:31.0) Gecko/20100101 Thunderbird/31.3.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>
In-Reply-To: <54C12D66.7050300@evolveum.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

Le 22/01/15 18:03, Radovan Semancik a écrit :
>
>> We have git mirror (read only). Have a look at the end of
>> http://directory.apache.org/sources.html
>>
>> There is also a github repo : https://github.com/apache/directory-shared
>
> Yes. I have seen that. But the question is: will you accept a
> contribution in a form of pull request on github?

I think so. We need to try !
> Ok, now some explaination on how the whole Schema system works.
>>
>> First of all, you have to understand that the API can work with our
>> without schema. The schema is really an optional piece. Now, when you
>> want to use a schema, all the methods will be passed an instance of what
>> we call an SchemaManager. So the very first thing you have to do is to
>> have an instance of a SchemaManager. How do you get such a beast ?
>>
>> The response will depend on where you pull the schema from. We use
>> SchemaLoader instance for that purpose, and we have various flavors :
>> - LdifSchemaLoader : loads all the schema elements from the disk,
>> assuming they are stored as LDIF
>> - SingleLdifSchemaLoader : same thing, but the schema elements are
>> stored in one single fiule instead of many
>> - JarLdifSchemaLoader : same thing, except that we are reading the
>> schema elements from a Jar file
>> - DefaultSchemaLoader : loads a schema directly from a server
>> The last one is most certainly what you are interested in. What it does
>> is that it reads all the stored schema elements description, in a format
>> that is described in RFC 4512. We pump the AT, OC, etc from the
>> subschema subentry. Usually, it's stored into the rootDSE.
>>
>> Once we have those elements, we parse them into something we can play
>> with, and when it's done, we check that the schema is consistent. If so,
>> you now have a valid SchemaManager that is going to be used all over the
>> API, silently - ie, you don't even have to tell the API to use it).
>>
>> At the end of the day, it boils down to create a LdapNetworkConnection,
>> call loadSchema() on it, and you are all set :
>>
>>                      connection = new LdapNetworkConnection(
>> configuration );
>>                      connection.loadSchema();
>>
>> That should work pristine with OpenLDAP.
>
> Yes. I have already figured that out.
> BTW, it would be great to copy&paste this text at a proper place at
> http://directory.apache.org/api/user-guide/4-schema-management.html

Exactly what I was telling myself : why the hell should I explain all
that again and again on the ML when it could be put on teh web site ...

> Especially the piece of code, together with
> schemaManager = connection.getSchemaManager();
> it took me a while to figure that out. Placing it in the guide will
> definitely help other developers.

+1
>
>> Now, there are two other use cases :
>> - first, you don't want to connect to a LDAP server (because you have
>> many possible ones), and you want a shared schema between those guys.
>> Here, I whish you good luck, as the schema will varry a lot between
>> OpenLDAP, AD, etc... Although you can make it work, but you have to load
>> the schema from some local data (here, it will be a LDIF file, using
>> ApacheDS format, or a OpenLDAP format file). if it's from a OpenLDPA
>> formated file, you will need to convert it, which is done by the
>> SchemaParser file.
>> - second, you want to connect to a LDAP server which uses a different
>> format. You will have to write a parser for what you get...
>>
>> My guess is that option 1 is the best for your need.
>
> It is option 2. I do want to connect to LDAP server and I want to
> download the schema and I want to process the schema dynamically. This
> is what a good IDM system does (such as midPoint :-)) ... and actualy
> all the code to process the schema is already in place is it work
> quite well with JNDI. Including the schema retrieval from the server.
> So I positively know that this is possible. I need to support only
> several schema styles (OpenLDAP, the Netscape family, OpenDS/OpenDJ
> and eDirectory). And there are all quite similar. Currently I do not
> really care about the rest. So this should be quite feasible.
>
> I do not really need the schema checking inside the API. MidPoint does
> that already. But having the checking is not a problem, it is just
> added benefit. 
The checking can be disabled.

> What I really need is to download the schema from LDAP server,
> represent it in the Apache LDAP API terms (ObjectClass, AttributeType
> and similar) . This is what I want to contribute to the API. Then my
> connector takes that and converts the schema to the ConnId
> terminology. This makes it a "universal" IDM schema which is not
> LDAP-specific. midPoint takes it from there ... and this is really a
> long story that is not important for this discussion.
>
> So it looks like all I need is to implement that "// TODO Handle
> schema loading on other LDAP servers" part, right? :-)

Most certainly. We use an antlr parser to do that with what we get from
OpenLDAP/ApacheDS, it should be easy to do the same thing for other servers.
>
>> What I would need at this point is an exact description of what you want
>> to do in order to drive you toward the various classes of teh API.
>
> Maybe if you can describe how to support OpenLDAP server there .... I
> think I can figure out the rest.

I'll do that after dinner.