[Schema awareness] About Schema/SchemaManager(changed the subject)

[Emmanuel Lecharny <el...@apache.org>]

On Mon, Nov 30, 2009 at 10:34 PM, Matthew Swift <Ma...@sun.com> wrote:
<snip/> It also breaks the RFC : a single server might define more than one
>> set of Schemas for a specific branch in the tree. (RFC 4512, par. 4.2)
>>
>>
>
> No - I think that you're misunderstanding me, it's my fault as I'm abusing
> the term singleton really :-/

Ok, pfewww :)


> Here I'm referring to three schemas: two built in fixed schema and one
> configurable:
>
>  1. The "core" schema containing the standard schema elements defined
>     in the LDAP RFCs(objectClass, cn, sn, etc)

Ok. In OpenLDAP and ADS, we have a few base schemas : 'core' for
OpenLDAP, plus 'system', 'apache' and 'apache-meta' for ADS. It's
difficult to use less than that, I guess it's pretty much the same for
OpenDS, except that you only have 'core'

They all contain base elements, plus some specific ones in our case.
The reason why they are separated is that w edon't think it's a good
idea to mix schema elements in one big phat schema file.


>  2. The "empty" schema which contains no schema elements but fakes up
>     attribute type definitions on demand (the core schema does this as
>     well for attribute types that it does not find). I'm not sure of
>     the value of this schema - but it's interesting to have I suppose :-)

We have the same kind of schema, named 'other'. Useful.

>  3. The global default schema - this can be modified by the
>     application at start up and is the one used for all operations
>     that require a schema but where the caller has not provided one.
>     For example, we have: DN.valueOf(String) and DN.valueOf(String,
>     Schema) --- the first uses the default schema. By default the
>     default schema is the core schema.

I don't really see what this global default schema can be good for
(it's not an opinion, it's just a question). In my mind, we always
have to load 'core', so this is the base schema anyway.

> Then we allow additional schemas to be constructed via a SchemaBuilder or
> downloaded from a Directory Server via the Connection API.

SchemaBuilder : close to SchemaManager :)

Let's try to sumarize, because I think we are tainted by our
implementation (which is plain normal ...) :

- what I call Schema is a file (or an instance of this file),
containing AT, OC, ..., and used internally as a container for the
SchemaObjects (AT, OC...)
- a SchemaObject is an instance of AT, OC, MR, etc
- the SchemaManager in our case is the class responsible for any
schema manipulation (including addition or removal of SchemaObjects,
or full Schema). It seems to be close to your SchemaBuilder, except
that in your case, it creates a Schema, which is the global container
(my understanding).

What I envision is that, if we keep the Schema as a container for some
set of SchemaObject, then we need some SchemaObjects container which
can be see by the client as the whole set of SchemaObjects he can
uses.

Now the fact that you call this global container "schema" conflicts
with the file containing a subset of SchemaObjects I call "Schema"
too. We have two solutions here :
1) We use another name for this global container
(SchemaHandler/Container/manager)
2) I rename the Schema to SchemaFile or SchemaContainer, and the
Schema is the global container.

Frankly, I don't like SchemaManager as a name exposed to users, as
they know about it as the Schema ( as a whole ), and I think that the
subdivision of SchemaObjects in what we called 'Schema' is just
implementation dependant, and I would rather rename those containers
SchemaContainer/File.

I'm quite sure you will lean toward this solution, I just want to be
sure that others agree with this vision, or not.

thanks !

>
> Does that make sense?
>
> I'll come back to your other points tomorrow.
>
> Matt
>
>



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