directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Wallace <rwall...@thewallacepack.net>
Subject Re: Proposed protocol-dns changes
Date Mon, 29 Jan 2007 15:59:43 GMT
Enrique Rodriguez wrote:
> I agree with most of your changes and I intend to apply the patch once
> we work out the test failure issue (binary PDU's missing).  It's good
> to see activity on the DNS protocol.  My synopsys of your patch was
> that it contained good updates to JDK 1.5 and a couple nice bug fixes
> plus new features around decoding, required for DNS clients.
>
> I thinks it's good practice to break a patch up into a couple smaller
> patches.  This patch broke in one place for me and there was the
> missing test files issue.  I would have been able to apply parts
> faster.  The patch naturally breaks down into sub-patches, which you
> were probably aware of as they are in order.  The order also
> corresponds nicely to increasing complexity/invasiveness and
> increasing broken-ness.  In short, the first 3 subpatches would have
> gone on relatively smoothly, leaving us to deal with the tests.
>
> 1-2)  enums, type-safe wrappers (JDK 1.5 updates)
> 3-6)  codec reorg w.r.t. MINA deps
> 7-8)  bug fixes
> 9-11)  test cases
>
I know, I agree.  I just got up a good head of steam and just kept
going.  I'll try and discipline myself a bit better in the future.
> The same concept goes for large emails, which makes it harder to find
> time to comment.
>
> Other comments:
>
> ...
>> 6) Moved all the (get|put)Unsigned(Byte|Short|Int) methods into a
>> utility class called ByteBufferUtil.
>
> Regarding #6, in the early days of MINA we found we had a need for
> unsigned values in various protocols so we put them directly on MINA's
> ByteBuffer:
>
> http://mina.apache.org/report/trunk/apidocs/org/apache/mina/common/ByteBuffer.html
>
>
> So, this may be a reason to use MINA ByteBuffer's.  
Ah.  I didn't know those methods were on the MINA ByteBuffers.  AFAIK
they weren't being used by the protocol-dns before.  A proposal came up
a while ago on the MINA list to create a separate jar that just had the
ByteBuffer in it.  I wouldn't mind seeing the shared code using
something like that.
> I also don't see
> any reason to reduce our dependency on MINA.  Especially with more
> complicated protocols, there is a need to use features of the
> framework to reduce complexity.  If the framework is truly pluggable,
> then it isn't a framework, it's a component.
>
My only issue is with being too tightly coupled to any framework.  I
love MINA.  It's the reason I'm interested in working on different
networking protocol implementations.  It's just really slick.  But, I've
learned not to put too many eggs in one basket. 

So what I'm suggesting we do is that most of our components should by
usable with any framework, such as the decoders/encoders and other core
classes.  Then we tie it all together with the framework using one or
two other components.  This is the same way the ldap protocol with the
ans1 encoding/decoding.

I kind of think of it like the OSGi stuff.  We don't want to integrate
OSGi related stuff into everything we're doing, so we have the separate
subprojects that tie in our OSGi code.


Rich

Mime
View raw message