You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Emmanuel Lécharny <el...@gmail.com> on 2012/02/14 14:55:06 UTC

SchemaManager : TODOs

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