Re: Message data structure merge heads up, take 3
On Sat, Aug 14, 2010 at 3:35 AM, Emmanuel Lecharny 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
On Sat, Aug 14, 2010 at 6:05 AM, Emmanuel Lecharny 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
Message data structure merge heads up, take 3
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