On Thu, Feb 24, 2011 at 8:50 PM, Kiran Ayyagari <kayyag...@apache.org> wrote:
> On Thu, Feb 24, 2011 at 11:12 PM, Emmanuel Lecharny <elecha...@gmail.com>
> wrote:
>> 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.
> having a single serializer class will force dependency on the packages
> that are not interested by a user trying to use just a portion of API
Yeah I did not think of this. Kiran is right. This will cause a single
point of dependency pulling in the kitchen sink. Rather we should have
different serializers for different classes.
Good catch Kiran,
Alex
