directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel L├ęcharny <elecha...@apache.org>
Subject Re: [Shared] Refactoring update: next steps
Date Mon, 24 Jan 2011 18:25:52 GMT
On 1/24/11 6:45 PM, Alex Karasulu wrote:
> On Monday, January 24, 2011, Emmanuel Lecharny<elecharny@gmail.com>  wrote:
>> On 1/24/11 4:20 PM, Alex Karasulu wrote:
>>
>> I've moved all the classes that compose the model into a model sub
>> package while removing codec dependencies. Next steps:
>>
>> (5) Apply Decorator to ldap-codec.
>>
>> I can handle this.
>>
> Thanks but I have already begun with files I have yet to commit. Also
> with my refactoring it will create many conflicts. So it's probably
> best that I handle it at least until some things stabilize.
Thinking again about those decorators :

if you encapsulate all the API objects into decorator, which adds the 
internal methods the codec engine needs, then in order to use them you 
will have to add a big if ( xxx instance of XXX) then new XXXDecorator( 
xxx) else ..., arent you ?

At this point, I think there is another approach that is cleaner. In the 
API, we have removed all the computeLength() etc methods from the base 
messages, and we are using a dedicated class (LdapEncoder) that acts as 
a kind of transformer.

I think we should just implement the missing encodeLength() et all 
methods for controls in this LdapEncoder class.

Please give it a look and tell me if it's ok before starting to write 
many decorators that might be spurious.

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


Mime
View raw message