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
