Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: pass (nike.apache.org: domain of elecharny@gmail.com designates
 209.85.214.50 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:reply-to:user-agent:mime-version:to:subject
         :references:in-reply-to:content-type:content-transfer-encoding;
        b=xrAblVZ0P9GyQrJK73F+Y0INgJl03c+OJkgMCaKhH+5OL4JiAosiuEWyiFVZekOJhV
         F36ceMuLGXxGQLFLOZ922ECEpMNkPe0jTTUtz4pD64oTe+8PAtbdl0X8kJR7g53TVxzu
         C1z38lCVNiIz6YE7v6SaOFe+wll09lf8SrQsA=
Message-ID: <4D66F144.8060506@gmail.com>
Date: Fri, 25 Feb 2011 01:01:08 +0100
From: Emmanuel Lecharny <elecharny@gmail.com>
Reply-To: elecharny@apache.org
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;
 rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: API cleanup update
References: <4D66987D.1040005@gmail.com>
	<AANLkTimWN+B9_GaDoPpGZt6Dim-Q_Lc8Ph9mVQr-wNuE@mail.gmail.com>
 <AANLkTikeYX2wg36dSvX59+jsL2fucLFDJ3T5a=dea7j=@mail.gmail.com>
In-Reply-To: <AANLkTikeYX2wg36dSvX59+jsL2fucLFDJ3T5a=dea7j=@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

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