[ApacheDS] merging various message structures

[Kiran Ayyagari <ka...@apache.org>]

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

    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.
    (currently client-api has another set of classes)

    We would like to work on these changes from tomorrow.

Kiran Ayyagari

Re: [ApacheDS] merging various message structures

[Emmanuel Lecharny <el...@gmail.com>]

  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

Re: [ApacheDS] merging various message structures

[Emmanuel Lecharny <el...@gmail.com>]

  Hi Kiran,


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
>
>      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.
>      (currently client-api has another set of classes)
>
>      We would like to work on these changes from tomorrow.
I'll give more substance to my answer later, but basically, let's do it 
! Can you create a branch for this purpose ?

Many thanks !

-- 

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