Message data structure merge heads up, take 3

[Emmanuel Lecharny <el...@gmail.com>]

  One step further :
- all the response have been migrated
- all the ldap-api response messages have been removed and replaced by 
the shared-ldap response messages

We now have one singe set of classes to manage responses, all over the 
server, except in the dsml-parser module (to be done)

The next step is to add the missing toString() methods in the Message 
(each codec message had a toString method), then to continue the 
migration of requests (compare, extended, modify, modifyDn, and search).

When done, we will be able to rename the Internalxxx to xxx (no reason 
anymore to have 'Internal' in front of each message).

I'm still wondering if it's a good idea to have an interface for each 
message. Not sure...

A few more thing we would like to do : there are many fields which are 
exposed as public (the various length, used to encode the messages), and 
I'm wondering if we could not hide them or at least keep them package 
protected. To be investigated.

All in all, this cleanup has removed 24 512 slocs (from 351 355 slocs 
down to 326 443 slocs). Not bad !


-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: Message data structure merge heads up, take 3

[Alex Karasulu <ak...@apache.org>]

On Sat, Aug 14, 2010 at 3:35 AM, Emmanuel Lecharny <el...@gmail.com>wrote:

>  One step further :
> - all the response have been migrated
> - all the ldap-api response messages have been removed and replaced by the
> shared-ldap response messages
>
> We now have one singe set of classes to manage responses, all over the
> server, except in the dsml-parser module (to be done)
>
> The next step is to add the missing toString() methods in the Message (each
> codec message had a toString method), then to continue the migration of
> requests (compare, extended, modify, modifyDn, and search).
>
> When done, we will be able to rename the Internalxxx to xxx (no reason
> anymore to have 'Internal' in front of each message).
>
>
+1 to remove Internal designator.


> I'm still wondering if it's a good idea to have an interface for each
> message. Not sure...
>
>
I favor the use of interfaces especially for API exposed elements other than
helper classes. We cannot foresee all the use cases in advance and
interfaces give us the greatest flexibility.

A few more thing we would like to do : there are many fields which are
> exposed as public (the various length, used to encode the messages), and I'm
> wondering if we could not hide them or at least keep them package protected.
> To be investigated.
>
>
Yeah I would imagine many things can be hidden.


> All in all, this cleanup has removed 24 512 slocs (from 351 355 slocs down
> to 326 443 slocs). Not bad !
>
>
Wow great job! Less code is always good.

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

Re: Message data structure merge heads up, take 3

[Kiran Ayyagari <ka...@apache.org>]

On Sat, Aug 14, 2010 at 6:05 AM, Emmanuel Lecharny <el...@gmail.com> wrote:
>  One step further :
> - all the response have been migrated
> - all the ldap-api response messages have been removed and replaced by the
> shared-ldap response messages
>
> We now have one singe set of classes to manage responses, all over the
> server, except in the dsml-parser module (to be done)
>
> The next step is to add the missing toString() methods in the Message (each
> codec message had a toString method), then to continue the migration of
> requests (compare, extended, modify, modifyDn, and search).
>
> When done, we will be able to rename the Internalxxx to xxx (no reason
> anymore to have 'Internal' in front of each message).
>
> I'm still wondering if it's a good idea to have an interface for each
> message. Not sure...
IMO not required, i don't think this part of the server is so
extendable and used anywhere else
>
> A few more thing we would like to do : there are many fields which are
> exposed as public (the various length, used to encode the messages), and I'm
> wondering if we could not hide them or at least keep them package protected.
> To be investigated.
>
> All in all, this cleanup has removed 24 512 slocs (from 351 355 slocs down
> to 326 443 slocs). Not bad !
yeah, a LOT of cleanup indeed

thanks Emmanuel

Kiran Ayyagari