directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject Do we need to keep the encoder/decoder Provider stuff ?
Date Mon, 09 Aug 2010 17:26:34 GMT
  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 ?

-- 
Regards,
Cordialement,
Emmanuel L├ęcharny
www.iktek.com


Mime
View raw message