Hi,
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.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com
