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
