directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject Re: API cleanup update
Date Fri, 25 Feb 2011 00:01:08 GMT
On 2/24/11 10:12 PM, Alex Karasulu wrote:
> On Thu, Feb 24, 2011 at 8:50 PM, Kiran Ayyagari<kayyagari@apache.org>  wrote:
>> On Thu, Feb 24, 2011 at 11:12 PM, Emmanuel Lecharny<elecharny@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.

Absolutely. At first, I thought it was a good idea to gather all the 
serializer in a single place, but Kiran has a valid point here...

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


Mime
View raw message