Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: pass (nike.apache.org: domain of elecharny@gmail.com designates
 74.125.82.44 as permitted sender)
Message-ID: <4F2FDF79.8070502@gmail.com>
Date: Mon, 06 Feb 2012 15:11:05 +0100
From: Emmanuel Lecharny <elecharny@gmail.com>
Reply-To: elecharny@apache.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6;
 rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Schema handling in the API : a sum up
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

So let me summarize many aspects we have discussed about the schema 
handling in the API in this mail.

 From the API POV, we should distinguish four cases :
- we don't want to load any schema
- we want to load a schema from a LDAP server
- we want to load a local schema (ie, from some files)


Case 1 : if we don't load any schema, then we won't have a 
SchemaManager, and the API will not be schema aware. This is what 
happens if you create a connection, and don't explicitely load a schema. 
So far, we already can work this way.

Case 2 : here, we connect to the server, and load the schema which is 
stored in the subschemaSubentry. This is done using the 
LdapConnection.loadSchema() method, which reads the schema from the 
SubschemaSubentry

Case 3 : we have 4 different schema loaders, depending on the file 
format that contains the schema (Multiple Ldif files, Single Ldif file, 
Jar, XML/OpenLDAP format files). In order to load a schema using one of 
those format, we just have to create a SchemaManager, passing it a 
SchemaLoader. If we want to use this SchemaManager in a connection, we 
can pass it using the LdapConnection.setSchemaManager( schemaManager ) 
method (note : this method must be added to the interface). It's also 
possible to do it directly by calling the LdapConnection.loadSchema( 
SchemaLoader ), without creating a SchemaManager.

In any case, the third case is to be used by advanced users, most of the 
users will either use the first or second solution.

Regarding the SchemaLoader names, we should keep it simple and explicit. 
Here are some suggestions :
- DefaultSchemaLoader : loads the schema from the SubschemaSubentry. 
It's currently named SsseSchemaLoader.
- (Ldif|JarLdif|SingleLdif)SchemaLoader : all the different format we 
support in ApacheDS.
- SchemaEditorSchemaLoader : loads the schema from a XML file or an 
OpenLDAP format
- SchemaPartitionSchemaLoader : This is to read the Schema from the 
Apacheds ou=schema partition

Also it would be good to move the ApacheDS specific SchemaLoader 
instances (ie, (Ldif|JarLdif|SingleLdif)SchemaLoader and 
SchemaPartitionSchemaLoader) into the ApacheDS project, as they don't 
belongs to the API. This will impact the tests, and we wil probably need 
to create a new projects to hold all the attached tests.

Thoughts ?

-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com