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 akarasulu@gmail.com designates
 74.125.82.44 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:content-type;
        b=WmkjMZxpKt48dJ3HWb6lIv/ktOdWkPrM+KNHrDz5U2TzsjpHcH68uO58UCc5fUefYY
         /NLqiEeAPCUXAa21FTRCo1GKS2vmrYMqbOVPimiaMDoERY9Y3Iw7vCKryJFnjdNNprwB
         oEul4+dqTNreHoUM830MdcNSNSMaFLtdeRLQA=
MIME-Version: 1.0
Sender: akarasulu@gmail.com
In-Reply-To: <4D5F5053.2040202@gmail.com>
References: <AANLkTimiVZMuKKcunoWXc1ptaU6OZrzz3__qBG86zBsW@mail.gmail.com>
	<4D5F5053.2040202@gmail.com>
Date: Sat, 19 Feb 2011 14:39:56 +0200
Message-ID: <AANLkTimR8wAZMCe0RUorFdUE55Aw6_itQ0AJ-8CHkdA-@mail.gmail.com>
Subject: Re: [Shared] [LDAP] [Codec] Anyone remember why we have two LDAP
 ProtocolDecoder implementations?
From: Alex Karasulu <akarasulu@apache.org>
To: Apache Directory Developers List <dev@directory.apache.org>,
 elecharny@apache.org
Content-Type: text/plain; charset=ISO-8859-1

On Sat, Feb 19, 2011 at 7:08 AM, Emmanuel Lecharny <elecharny@gmail.com> wrote:
> On 2/19/11 5:21 AM, Alex Karasulu wrote:
>>
>> I found these two classes here [0] and here [1]. Both implement
>> ProtocolDecoder and seem to be almost identical in capability.
>>
>> One seems to have been written for the client and one for the server
>> but I don't think it makes a difference. Perhaps these two can be
>> consolidated into single implementation.
>
> Definitively, yes.
>>
>> Incidentally the LdapProtocolEncoder is shared by both
>> LdapProtocolCodecFactory implementations in shared and in apacheds.
>> This means if we consolidate these two classes, [0] and [1], then we
>> can easily consolidate the two codec factories.
>
> Ok, let me explain why we have 2 classes. The older one was the server one,
> which was using a complex pattern with a callback, a blocking and not
> blocking decode methods, etc. The newer one was developed for the client,
> and is what we should have had from day one in the server.
>
> Both implementations should have been merged a while back, but it was not
> simple and some convergence started last september, not finished of course.
>
> So, yes, we should have one single implementation. The client implementation
> is probably the correct base to start with.

You mind looking into merging these two for me while I push forward
with remaining issues? I want to make the protocol codec factory
pluggable as well as the other things so later on if we like we can
whip up different factories for other MINA like frameworks.

Regards,
Alex