[...]
So far in our prototype SDK we haven't needed a SchemaManager. We provide
access to the singleton Schema objects directly from the Schema class (e.g.
Schema.getCoreSchema(), Schema.getDefaultSchema(), etc).
Singleton ? Yuk !!! Does not fit at all if you want to embed more than
one instance of the server : typically something one can do when
writing a VD !
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 :-/
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)
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 :-)
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.
Then we allow additional schemas to be constructed via a SchemaBuilder
or downloaded from a Directory Server via the Connection API.
Does that make sense?
I'll come back to your other points tomorrow.
Matt
