directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <akaras...@apache.org>
Subject Re: [Shared] Refactoring Update: The Control FREAK Chapter
Date Wed, 26 Jan 2011 04:24:03 GMT
FYI I started renaming some controls to keep them short by removing
the Control portions from them. This might not have been a good move.
Just wanted to give you guys a heads up that I'll probably revert it.
I was thinking the control being in it's own package and having a
clear enough class name would cue in readers of the code. Not sure
this is the case now.

On Wed, Jan 26, 2011 at 6:14 AM, Alex Karasulu <akarasulu@apache.org> wrote:
> Hi y'all,
>
> Tonight was like hell dealing with the codec code trying to figure out how to:
>
>   (1) Make the Control handling pluggable so new controls can be
> added to the codec
>   (2) Completing the application of the decorator pattern to the
> Control size of the codec
>   (3) Figuring out how to remove all the dependencies strewn all over
> on codec internals
>
> So why are there so many problems: (point by point respectively)
>
>   (1) Controls are hard coded into the codec: i.e. ControlFactory
> using a static method to create control instances. Instead we need a
> registration mechanism where a Control can register it self (decoder
> ctrl class etc).
>   (2) Seems we only applied one piece of this: to the encoding side,
> the decoding side still remains
>   (3) The control objects are both Asn1Objects, and CodecControl
> implementations at the same time. They are also referred to all over
> the place to access their OID constants. Hence pulling in codec
> dependencies many of which are implementation specific.
>
> NOTE: Same problems probably will occur with ExtendedRequest/Response
> handling since this needs to also be pluggable. Yeah OK the server
> always needs some hard coding to handle controls and extended
> request/responses so pluggability is not a major concern here. I think
> we need to be pluggable mostly for the client. Thoughts?
>
> Tonight sucked big time morale wise since I thought much of this was
> out of the way once the encoder side was done. But "surprise, you
> forgot the decoder beotch," was what my IDE said to me when I started
> separating out the model classes into the ldap-model module. Now I'll
> have to start over after fixing these Control issues (no big deal tho)
> because of several changes in shared-ldap again. I had svn copied it
> to ldap-model and began stripping out non-model packages. Will defer
> this until after the control issues are fixed.
>
> Anyways this is going to take longer and a bit more collaboration.
> It's not trivial.
>
> The build is messed up from changes we made early (late?) in the
> evening last night trying to finally decouple this SearchRequestImpl
> class. Thanks to Emmanuel we were able to do this and take care of the
> ModifyRequest handling.  We probably should have branched the trunk
> but oh well it is what it is now. Let's just try to get past it
> quickly.
>
> --
> 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
>



-- 
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

Mime
View raw message