directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject Re: [ApacheDS] merging various message structures
Date Thu, 05 Aug 2010 00:29:30 GMT
  hi,

my extended answer inlined ...

On 8/4/10 7:22 PM, Kiran Ayyagari wrote:
> hello guys,
>
>        Currently in the server we use more than one similar message
> structures at various levels of
>        processing to represent the same message type.
>
>      e.x
>        for a add request we use 'AddRequestCodec' during the encoding phase and
>        'AddRequestImpl' to be used by the server in the later phases
It's even worst : the ldap-client-api module define its own set of Ldap 
messages, too. So we have *three* different classes for the very same 
thing ! Crazy...
>      similarly there are several message structures who are mostly
> identical. Merging them will
>      improve the performance of the network layer and also allows
> client-api to use these classes directly.
Yes.

>      (currently client-api has another set of classes)
eh eh eh...

Now, there is a reason why we have those three different set of classes. 
It's mainly historical.

At the origin, the server used a set of classes with a high level of 
inheritance. For instance, the AddRequest class is implemented this way :

AddRequestImpl extends AbstractAbandonableRequest implements 
InternalAddRequest
   InternalAddRequest extends SingleReplyRequest, InternalAbandonableRequest
     SingleReplyRequest extends InternalResultResponseRequest
       InternalResultResponseRequest extends InternalRequest
         InternalRequest extends InternalMessage
     InternalAbandonableRequest extends InternalRequest
   AbstractAbandonableRequest  extends InternalAbstractRequest 
implements InternalAbandonableRequest
     InternalAbstractRequest extends InternalAbstractMessage implements 
InternalRequest
       InternalAbstractMessage implements InternalMessage

Not that simple :/ But it was - and still is - consistent.

The problem with this hierarchy is that decoding and encoding messages 
was difficult, as we had to wait to know which kind of message to 
construct until we have enough decoded parts of the received PDU (in 
restrospect, this was a wrong assumption). But more critical is the 
encoding : in order to be fast, the encoder was associated with each 
class (ie, an instance was able to encode itself). The reason to do that 
is that we needed to get the PDU size *before* being able to generate 
the PDU itself (the PDU size is enclosed into the PDU, somehow).

Again, this was a good way to deal with encoding/decoding complexity, as 
the hierarchy  designed to do so was simpler. Also because the initial 
server architecture allowed the implementation of independent codec, it 
was possible to implement the codec using its own set of classes : a 
Transformer was used to do the conversion.

All those good reasons now are falling into the 'overkilling' category. 
There is no more compelling reasons not to merge all those classes in 
one single hierarchy.

So let's do it, now.


-- 
Regards,
Cordialement,
Emmanuel L├ęcharny
www.iktek.com


Mime
View raw message