You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Emmanuel Lecharny <el...@gmail.com> on 2012/02/06 09:57:09 UTC
SchemaLoaders : another approach.
May be we are looking at the problem from the wrong side.
All in all, is the user interested into the class used to load the
schema ? What about telling the SchemaManager to load the schema, and
telling it to use a schemaLoader of our choice if needed ?
As of today, we do :
SchemaLoader loader = new NetworkSchemaLoader( connection );
// Load the schemas
SchemaManager schemaManager = new DefaultSchemaManager( loader );
What if we do :
SchemaManager schemaManager = new DefaultSchemaManager( loader );
schemaManager.loadFromSubentry();
?
We would have :
schemaManager.loadFromLdif();
schemaManager.loadFromJar();
schemaManager.loadFromSingleLdif();
schemaManager.loadFromSubentry();
schemaManager.loadFromAds();
And for those who would like to use another schemaLoader, we could also
have :
schemaManager.load( schemaLoader );
We then could 'hide' the existing SchemaLoader, ie not expose them to
the public.
From the user POV, that would probably be easier, no ?
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: SchemaLoaders : another approach.
Posted by Emmanuel Lécharny <el...@apache.org>.
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
Re: SchemaLoaders : another approach.
Posted by Pierre-Arnaud Marcelot <pa...@marcelot.net>.
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.
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.
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 think we should always think about not overloading the API with two many methods and always focus on having one simple method for casual user and one more complex for more experienced users (usually by providing a specific class instance of their choice).
Regards,
Pierre-Arnaud
On 6 févr. 2012, at 09:57, Emmanuel Lecharny wrote:
> May be we are looking at the problem from the wrong side.
>
> All in all, is the user interested into the class used to load the schema ? What about telling the SchemaManager to load the schema, and telling it to use a schemaLoader of our choice if needed ?
>
> As of today, we do :
>
> SchemaLoader loader = new NetworkSchemaLoader( connection );
>
> // Load the schemas
> SchemaManager schemaManager = new DefaultSchemaManager( loader );
>
> What if we do :
>
> SchemaManager schemaManager = new DefaultSchemaManager( loader );
> schemaManager.loadFromSubentry();
>
> ?
>
> We would have :
>
> schemaManager.loadFromLdif();
> schemaManager.loadFromJar();
> schemaManager.loadFromSingleLdif();
> schemaManager.loadFromSubentry();
> schemaManager.loadFromAds();
>
> And for those who would like to use another schemaLoader, we could also have :
>
> schemaManager.load( schemaLoader );
>
> We then could 'hide' the existing SchemaLoader, ie not expose them to the public.
> From the user POV, that would probably be easier, no ?
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
Re: SchemaLoaders : another approach.
Posted by Kiran Ayyagari <ka...@apache.org>.
On Mon, Feb 6, 2012 at 2:27 PM, Emmanuel Lecharny <el...@gmail.com> wrote:
> May be we are looking at the problem from the wrong side.
>
> All in all, is the user interested into the class used to load the schema ?
> What about telling the SchemaManager to load the schema, and telling it to
> use a schemaLoader of our choice if needed ?
>
a very interesting proposal
> As of today, we do :
>
> SchemaLoader loader = new NetworkSchemaLoader( connection );
>
> // Load the schemas
> SchemaManager schemaManager = new DefaultSchemaManager( loader );
>
> What if we do :
>
> SchemaManager schemaManager = new DefaultSchemaManager( loader );
> schemaManager.loadFromSubentry();
>
> ?
>
> We would have :
>
> schemaManager.loadFromLdif();
> schemaManager.loadFromJar();
> schemaManager.loadFromSingleLdif();
> schemaManager.loadFromSubentry();
+1
> schemaManager.loadFromAds();
>
this will add some unwanted coupling with the network layer, should
better be loaded
using the below mentioned load( schemaLoader ) method
> And for those who would like to use another schemaLoader, we could also have
> :
>
> schemaManager.load( schemaLoader );
>
> We then could 'hide' the existing SchemaLoader, ie not expose them to the
> public.
> From the user POV, that would probably be easier, no ?
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
--
Kiran Ayyagari