directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel L├ęcharny <>
Subject reworking the codec
Date Mon, 08 Feb 2010 00:24:44 GMT

As I'm refactoring the global Message hierarchy, I started with 
something simpler to begin with : simplify the waay the codec works.

Some explanations : when I rewrote this part 5 years ago (yeah, time 
flies...), I stuck to the RFC up to a point I had to define a complete 
set of new classes for all the messages. They are named xxxCodec now. 
Alex defined a much better hierarchy back then, but as the decoding 
process was done in a quite different manner, it was a compromise I was 
ready to accept. The good thing is that Alex anticipated such a need, 
and designed a Transformer to switch from the codec format to the 
internal format. That saved me !

Now, I realize I have done a big mistake. Not that it does not work, but 
it's really way more complex than necessary. What was the mistake ? 
Simple : a message is a composition of an Id, a protocolOp and controls. 
I mapped all the requests and responses to the protocolOp, and I 
designed a specific container called LdapMessage in which I stored the 
Id, the controls, and the protocolOp.

It was stupid : the protocolOp is really the typed message, no need to 
define a container.

Why did I do that ? Because when you have to decode an ASN.1 PDU, the 
messageId comes *before* the protocolOp. So I created a neutral 
LdapMessage in order to store the messageId, the  the protocolOp ad the 
codecs at the end. I realized yesterday that it was easy to store the 
messageId somewhere, avoiding the creation of a LdapMessage object, as I 
was able to know which exact kind of instance I have to create 
immediately after having decoded the Id. Then it was just a matter of 
grabbing the Id, and stores it in the instance.

So I did it, and it works. I just validated this approach on the 
Abandonrequest atm, but it will be pretty fast to move all the other 
requests and responses to such a mechanism (I already have done half of 
the work).

The next step will be to remove the encoding from the messages, as there 
is no reason to tie them two. If we want to encode a message to DSML, we 
have to use an external mechanism already, so we can do the same for 
ASN.1. There should be no penalty to pay for such a refactoring.

Once those two steps will be achieved, we will be able to merge the 
codec messages with the internal messages, and to remove the useless 
transformer. Last, not least, we won't have to define a full set of 
messages in the API.

At the end of the day, it will be faster, easier to manipulate and 
unique. And we will have less code :)

This is what I probably will work on the next few days.

Emmanuel L├ęcharny

View raw message