On Mon, Aug 9, 2010 at 10:56 PM, Emmanuel Lecharny <[email protected]> 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.
>
> 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...
>
> 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
thanks Emmanuel
Kiran Ayyagari
