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
