Hi guys,
as we are trying to work on a Schema Aware API, we are facing some
issues when it comes to connect and work with some other LdapServer,
like OpenLDaP, AD, etc. Those issues were expected, and there is nothing
serious, but we need to do some refactoring in order to ease the pain.
Here is a list of known issues :
o We have a mixed model for SchemaObject. They are mutable, they don't
hold everything we need in the server, the APi and studio, and it's not
versatile. We need to create a Immutable SchemaObject model, and have
mutable objects we can use in Studio
o We have some methods in SchemaObject classes that does not belong to
those classes : addToRegistries(), for instance, should be a
SchemaManager method
o We need place holder schemaObjects, when we connect to a server which
is not exposing all the SchemaObject we expect. For instance, openLDAP
does not expose the AttributeTypeDescritpion syntax, and 13 other
syntaxes referenced by ATs. AD does not expose any syntax at all, etc.
Using a fake SchemaObject is mandatory to avoid NPE and other bizarre
behaviors
o We need to handle MRU, NF, DCR and DSR
o We need to make a distinction between a Schema and a Schema file.
Schema is the whole stuff, with all teh AT, OC etc. A SchemaFile is just
a part of it. Currently we use Schema to describe files, not to describe
the while set of SchemaObject. This must be clarified
o We have a lot of useless conversions done. For instance, to load the
schema from a remote server, we get the elements in a RDC format,
convert them to SchemaObjects, then convert them to Entries, then we
convert them to SchemaObjects again, because all those conversions are
done inside some private methods. We must only use one pivot format, the
SchemaObject, and convertto and from this format
o We need to add decorators around existing SchemaObject to do those
conversions (in and out)
o We need to add some listeners in the SchemaManager to allow a third
party (namely, studio) to know when something has changed in the schema
All those items are not complex ones, we are close to have something
which can be use almost everywhere, but we need to get those items fixed
if we want to have a solid and stable release. I'm going to address some
of those points asap.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
