directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kiran Ayyagari <kayyag...@apache.org>
Subject Re: API cleanup update
Date Thu, 24 Feb 2011 18:50:29 GMT
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
for e.x if I want to customize a particular module and only interested
in serializing Entry classes the suggested serializer class will
require
ldif module too, even if it is not required
> 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
>
>



-- 
Kiran Ayyagari

Mime
View raw message