directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <akaras...@apache.org>
Subject [Shared] Refactoring Update: The Control FREAK Chapter
Date Wed, 26 Jan 2011 04:14:22 GMT
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

Mime
View raw message