Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Message-ID: <4F2FA52B.7050306@apache.org>
Date: Mon, 06 Feb 2012 11:02:19 +0100
From: =?UTF-8?B?RW1tYW51ZWwgTMOpY2hhcm55?= <elecharny@apache.org>
Reply-To: elecharny@apache.org
Organization: The Apache Software Foundation
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: Re: SchemaLoaders : another approach.
References: <4F2F95E5.7080500@gmail.com>
 <BE586701-F4BD-482B-A167-829A5E66A254@marcelot.net>
In-Reply-To: <BE586701-F4BD-482B-A167-829A5E66A254@marcelot.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 2/6/12 10:20 AM, Pierre-Arnaud Marcelot wrote:
> I really like the idea too, but I think we can combine both approaches.
>
> I see the SchemaManager more of an internal class and not something that someone (except experts) would instantiate.
Agreed.
>
> To ease the loading of the Schema and make the API schema aware, avoiding issues with binary attributes (for example), I would recommend to let the SchemaManager.load(SchemaLoader) or SchemaManager.setSchemaLoader(SchemaLoader) method, without any other easy to use method.
> I don't see users of the API having to manually create an instance of SchemaManager.
At the very beginning of the API discussions, we agreed on the fact that 
the API *must* be schema aware in any case, be it a default subset of 
schema. The user is allowed to override this default schema by injecting 
its own schema.

That means the default behavior, when defining a connection, is to load 
the schema from the LDIF file.

Then the user can load the schema from a server (either ADS, using the 
ou=schema partition, or using the subschemaSubentry).

That should be the two basic options our user have.

Extending that by allowing the use of some specific SchemaLoader is of 
course easy.

>
> On the other hand I would add new methods to the LdapNetworkConnection which is the base of the API and is used by 100% of our users (novice or experts).
> I would add two methods:
> - loadSchema(), targeted to casual users, which would load the Schema over the wire using the DefaultNetworkSchemaLoader (the one searching schema elements via the subSchemaSubEntry)
> - loadSchema(SchemaLoader), target to more experienced users, which is meant  allow any kind of Schema loading, be it over the wire or reading ldif or plain files on disk.

I would even get rid of the loadSchema() method, or make it read the 
schema from the subschemaSubentry. I'd like the API to follow this logic

- the default connection will load the schema from the API default 
schema (ie, from the LDIF jar file)
- or ask the connection to load the schema from the server 
(SubschemaSubentre) using loadSchema()
- or specify a specific schemaLoader using loadSchema(SchemaLoader)

That would simplify greatly the API, imho.

One other important aspect I'd like to stress out : In LDAP, the schemas 
are stored in subentry with the Subschema Objectclass, and can be 
pointed to by entries containing the SubschemaSubentry AT. The RootDSE 
contains such an attribute, and has an entry (cn=entry) storing the 
active schema elements. We may have more than one schema defined in the 
DIT, as soon as we have defined as many administrative point refering to 
them.
That make it possible to load more than one schema into a connection, 
even if usually, most of the servers does have only one subschema 
available (cf RFC 4512, par 4.2).

For the 1.0 version, I would suggest we only support the 
subschemaSubentry pointed by the rootDSE.

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