directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Trustin Lee" <>
Subject Re: DHCP Protocol Home (was: Re: [Vote] Sandboxing DHCP protocol)
Date Mon, 11 Jun 2007 23:53:34 GMT
Hi Alex,

On 6/12/07, Alex Karasulu <> wrote:
> The question is not where DHCP will go. It's definitely slated for
> inclusion in ApacheDS to fullfil the Realm Controller concepts.
> So, this is not a matter of whether or not it deserves to be here at
> Directory. I don't want to turn this into that kind of discussion.
> This is just a matter of maturity and documentation I think.
> IMO MINA should not be the place to host all protocols. It can for
> some time host protocols specific projects that do not have critical
> community mass (like Asynchweb) until they blossom. But to try to
> build MINA out to be a massive TLP in this way is a big mistake and
> will result in the same issues that have confronted Jakarta. Keeping
the TLP lean and mean will keep it functional. I'd love tho to see
> protocol analyzers and other protocol development tooling sub-projects
> start at MINA tho.

Well, DHCP can be used for other purposes, too.  So, in the same
context, Directory project doesn't absolutely need to host it, either,
because Directory project doesn't absolutely need to be the place to
host all related protocol codecs such as DNS, DHCP, and Kerberos, and
that's why we are sandboxing some protocols that we can't maintain.
Of course, it never means that Directory project doesn't deserve to
host those protocols; they are quite related with LDAP.  It's a matter
of point of view, and I understand your opinion and my opinion can be

I never believe MINA project team can adopt DHCP or other protocol
codecs right now because we are very busy enough working on various
transports and modifying the core.  It will be quite far future when
we consider whether we provide many protocol codecs including
essential ones that boosts network application development (i.e. HTTP,
SMTP, FTP).  But I also think providing a codec for less popular
protocols such as DNS will be beneficial for those who want to build a
light weight name service.

Moreover, we will do our best to implement such a codec in joint with
existing project team (or author) such as dnsjava.  For example, we
could reuse dnsjava's DNS message model and encoding/decoding code,
and provide its simple wrapper for MINA, which is a very thin
integration layer. As for AsyncWeb, I agree with you, and the same
approach can be applied to it too like we are going to do with DNS
once it goes TLP since its growth.

However, if there's no Java protocol codec implementation and MINA
needs to provide integration with the protocol, MINA team could
provide the codec if there are *enough* people who are interested in

Actually, we really need to wait and see what's going on while we do
what we have to do for now because someone might appear someday and
say 'hey I implemented protocol XXX!', and then we don't need to worry
about hosting all protocols. :)

what we call human nature is actually human habit
PGP Key ID: 0x0255ECA6

View raw message