On Mon, Nov 30, 2009 at 10:34 PM, Matthew Swift <[email protected]> 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
