directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject API cleanup update
Date Thu, 24 Feb 2011 17:42:21 GMT
Hi guys,

just a quick heads up about what I'm working on.

Currently, I'm removing all the useless Serializable implementation. I 
think we went anal by declaring a lot of classes to be Sezializable, 
when there is no reason for those classes to be serialized in any way. I 
have removed the implementation for those classes :
(DirectoryServiceOperation) -> ChangePassword, GetCatalog, GetPrincipal
Value
BitString
OID
Csn
[Permission] -> {ItemPermission, UserPermission}
[UserClass] -> {AllUsers, ParentOfEntry, Subtree, ThisEntry, 
[NamedUserClass] -> {Name, UserGroup}}
(SchemaObject) -> [AbstractSchemaObject] -> {AttributeType, 
DITContentRule, DITStructureRule, LdapSyntax,
     [LoadableSchemaObject] ->{LdapComparatorDescription, [Normalizer] 
-> {…}, NormalizerDescription,
     [SyntaxChecker] -> {…}, SyntaxCheckerDescription}, MatchingRule, 
MatchingRuleUse, NameForm, ObjectClass}

(xxx) are interfaces, [xxx] are Abstract classes.

I still have the LdapComparator and the classes extending it 
implementing Serializable, because JDBM serialize some comparators. I 
trully think it's a confusion we should get rid of. There is no need to 
serialize SchemaObject elements into the backend, when we just want to 
now which comparator to use. Up to a point, the Table knows which kind 
of SchemaObject it stores, and can grab the associated comparator using 
the SchemaManager. However, this is an area I'm not comfortable with so 
I keep those classes implementing Serializable.

I'll do the same work for Externalizable, here are the classes 
implementing this interface :
Externalizable classes :
------------------------
LdapPrincipal
ChangeLogEvent
ReplicaEventMessage
ParentIdAndRdn
(Entry) -> DefaultEntry, ImmutableEntry, ClonedServerEntry, 
ClonedServerEntrySearch
(EntryAttribute) -> DefaultEntryAttribute
(Modification) -> DefaultModification
(Value) -> [AbstractValue] -> {BinaryValue, StringValue}
LdifEntry
Ava
Rdn


AFAICT, all of them have to be externalizable, because they all get 
serialized at one point of another in the server (either in the backend, 
or in the changeLog)

However, I do think that depending on the default serialization process 
is a *bad* thing : it's costly, and can be avoided. We cureently have a 
few static classes (DnSerializer, RdnSerializer, AvaSerializer, 
EntrySerializer) which handle the optimal serialization, we should add 
some more.

Alex suggested to design a single Serializer class which can handle all 
those serialization/deserialization, I'm 100% with him on that.

The target is to be able to finish the Dn/Rdn/Ava cleanup, for what it 
worth...

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


Mime
View raw message