Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 27278 invoked from network); 11 Aug 2010 20:17:26 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 11 Aug 2010 20:17:26 -0000 Received: (qmail 3624 invoked by uid 500); 11 Aug 2010 20:17:26 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 3591 invoked by uid 500); 11 Aug 2010 20:17:25 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 3583 invoked by uid 99); 11 Aug 2010 20:17:25 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 11 Aug 2010 20:17:25 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of akarasulu@gmail.com designates 209.85.161.50 as permitted sender) Received: from [209.85.161.50] (HELO mail-fx0-f50.google.com) (209.85.161.50) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 11 Aug 2010 20:17:18 +0000 Received: by fxm20 with SMTP id 20so526432fxm.37 for ; Wed, 11 Aug 2010 13:16:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=5PGjVu48nzxsdzoibWKCqVajfoGFu2VN3I9jAmghpno=; b=V85R04bv2a5aXAq86MjGWf5kA4G3Mgt8bKRFGqISzl5AO7TtgZJkEf7AmghBYM1quK bdK8E+ddSJK1n0bwIoVW0cOHLzixTjPYgWztk3oeuuLPF/89Nr7didyj/PL+MIXAl58W V6+Nqd+2zTgELDc1h6HXyULJKGarb53jYWa5M= 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=Mn/pfeIecXH78awpEaeO+o2w60HGhJg7B1+TBPKUQgUY0T4zQ2+S88UMzopKPvdhKH gi03sp8qQZfy6t+4aZAkir+kN2l/G/YBWibHnd/6FEcWiUd+shrK9apDKbrTD4QSqEWf zfrKTvG+epzMr/v4Jkv+AlPM+qJWUDLmn+HR4= MIME-Version: 1.0 Received: by 10.239.132.67 with SMTP id 3mr903518hbq.204.1281557815834; Wed, 11 Aug 2010 13:16:55 -0700 (PDT) Sender: akarasulu@gmail.com Received: by 10.239.190.78 with HTTP; Wed, 11 Aug 2010 13:16:55 -0700 (PDT) In-Reply-To: References: <4C603A4A.8030609@gmail.com> Date: Wed, 11 Aug 2010 23:16:55 +0300 X-Google-Sender-Auth: B-8LDXZ3U70a-d9l0w3kfpT2O1M Message-ID: Subject: Re: Do we need to keep the encoder/decoder Provider stuff ? From: Alex Karasulu To: Apache Directory Developers List Content-Type: multipart/alternative; boundary=001485f44d625f37ad048d91eea6 X-Virus-Checked: Checked by ClamAV on apache.org --001485f44d625f37ad048d91eea6 Content-Type: text/plain; charset=ISO-8859-1 Hi Emmanuel, Kiran, guys n gals, On Mon, Aug 9, 2010 at 9:19 PM, Kiran Ayyagari wrote: > On Mon, Aug 9, 2010 at 10:56 PM, Emmanuel Lecharny > wrote: > > Hi, > > > > once upon a time, ie, 8 years ago, Alex codec the network frontend by > > assuming that there will be some other codec used later. It made perfect > > sense back then, as he first used an ASN.1 based codec named Snacc, which > > was not ASL.2 compatible. Then he had to change and define its own > version > > of an ASN.1 codec, but as he wanted to check that the new codec was > valid, > > he designed the system to be able to switch the codec just to know if the > > new codec was responsible for the failures he met, or something else. > > > > The rational was : > > - if the server behaves the same way whether Snacc or Snickers (the new > > codec) is used, then if the server has an issue, it means the codec is > not > > responsible > > - OTOH, if the server behaves differently, then it's likey the new codec > the > > cause of the problem. > > > > That was a smart move, and it was leveraged again when I wrote Twix, the > > third codec. I was able to do the same thing : compare the results > obtained > > with twix with what was obtained with Snickers. > > > > Eventually, we decided to ditch Snickers and to keep Twix, which was > > renamed. > > > > So as of today, we use the so-called twix internally. > > > Real nice recap of our codec development history. I enjoyed reading it and remembering the last 8 years. > Now, we still have a lot of remaining plumbery in place : all the classes > > needed to declare which codec to use. Mainly, we have : > > - Provider, an abstract class in charge of class loading the LdapProvider > > - LdapProvider, a class used to create the LdapEncoder and LdapDecoder > > > > Those two classes are created when we create the FilterChain as soon as a > > new session is initialized. More specifically, the ProtocolCodecFilter is > > added into the chain, and before we can process any incoming messages > from > > the client, we initialize the codec, using the LdapProtocolCodecFactory > > class to create the encoder/decoder instances. > > > > What are the essential elements ? > > - the factory > > - the encoder > > - the decoder > > > > We should be able to get rid of the provider, assuming we won't even > switch > > the codec in the near or distant future. That would simplify the code > which > > is, to say the least, cryptic... > > Exactly how much code are we talking about getting rid of? If I remember correctly there was not that much to this code. Hopefully as Kiran writes below these details are not exposed to the end user of the API however they do have the power to change the codec. It by default uses the TWIX codec. > > so, wdyt ? Should we keep the machinery that allow us to change the codec > by > > using an environment variable ? > IMHO let us keep it, AFAIU this is transparent to the end or API user > right? if yes, then I think it is > better to remove it in another release. > > P.S:- perhaps this will save us some debug headaches, if at all arise, > as we are making great > level of refactoring for the upcoming 2.0 > > If Kiran is correct about the exposure to the API end user, then I agree with Kiran here unless of course there's a lot of headache you're dealing with because of this Emmanuel. If you feel it's too much of a problem just nix it. Thanks, -- Alex Karasulu My Blog :: http://www.jroller.com/akarasulu/ Apache Directory Server :: http://directory.apache.org Apache MINA :: http://mina.apache.org To set up a meeting with me: http://tungle.me/AlexKarasulu --001485f44d625f37ad048d91eea6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Emmanuel, Kiran, guys n gals,

On Mon, = Aug 9, 2010 at 9:19 PM, Kiran Ayyagari <kayyagari@apache.org> wrote:
On Mon, Aug 9, 2010 at 10:56 PM, Emmanuel= Lecharny <elecharny@gmail.com> wrote:
> =A0Hi,
>
> once upon a time, ie, 8 years ago, Alex codec the network frontend by<= br> > assuming that there will be some other codec used later. It made perfe= ct
> sense back then, as he first used an ASN.1 based codec named Snacc, wh= ich
> was not ASL.2 compatible. Then he had to change and define its own ver= sion
> of an ASN.1 codec, but as he wanted to check that the new codec was va= lid,
> he designed the system to be able to switch the codec just to know if = the
> new codec was responsible for the failures he met, or something else.<= br> >
> The rational was :
> - if the server behaves the same way whether Snacc or Snickers (the ne= w
> codec) is used, then if the server has an issue, it means the codec is= not
> responsible
> - OTOH, if the server behaves differently, then it's likey the new= codec the
> cause of the problem.
>
> That was a smart move, and it was leveraged again when I wrote Twix, t= he
> third codec. I was able to do the same thing : compare the results obt= ained
> with twix with what was obtained with Snickers.
>
> Eventually, we decided to ditch Snickers and to keep Twix, which was > renamed.
>
> So as of today, we use the so-called twix internally.
>


> Now, we still have a lot of remaining plumbery in place : all the clas= ses
> needed to declare which codec to use. Mainly, we have :
> - Provider, an abstract class in charge of class loading the LdapProvi= der
> - LdapProvider, a class used to create the LdapEncoder and LdapDecoder=
>
> Those two classes are created when we create the FilterChain as soon a= s a
> new session is initialized. More specifically, the ProtocolCodecFilter= is
> added into the chain, and before we can process any incoming messages = from
> the client, we initialize the codec, using the LdapProtocolCodecFactor= y
> class to create the encoder/decoder instances.
>
> What are the essential elements ?
> - the factory
> - the encoder
> - the decoder
>
> We should be able to get rid of the provider, assuming we won't ev= en switch
> the codec in the near or distant future. That would simplify the code = which
> is, to say the least, cryptic...


=A0
> so, wdyt ? Should we keep the machinery that allow us to change the co= dec by
> using an environment variable ?
IMHO let us keep it, AFAIU this is transparent to the end or AP= I user
right? if yes, then I think it is
better to remove it in another release.

P.S:- perhaps this will save us some debug headaches, if at all arise,
as we are making great
=A0 =A0 =A0 =A0 level of refactoring for the upcoming 2.0


If Kiran is correct about the exposure to the API e= nd user, then I agree with Kiran here unless of course there's a lot of= headache you're dealing with because of this Emmanuel. If you feel it&= #39;s too much of a problem just nix it.

Thanks,
--
Alex Karasulu
My Blog :: <= a href=3D"http://www.jroller.com/akarasulu/">http://www.jroller.com/akarasu= lu/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org
To set up a meeting with me: http://tungle.me/AlexKarasulu
--001485f44d625f37ad048d91eea6--