directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <>
Subject Re: DNS Protocol (Was: DHCP Protocol Home)
Date Thu, 21 Jun 2007 08:47:21 GMT
Trustin Lee wrote:
> On 6/20/07, Brian Wellington <> wrote:
>> Trustin Lee wrote:
>> > Our primary goal is not about forking dnsjava.  I think it's our last
>> > resort.  Especially, I appreciate your effort to maintain dnsjava
>> > project as a previous user and a fan.  With a bigger community, we
>> > could cope better with such a big request because it's not only you
>> > but all committers will have more chance to consider about the worth
>> > of the request.
>> Definitely.  If there are people interested in working on DNS code, I'm
>> happy to let them.  The fact that I've written almost all of dnsjava is
>> more a reflection of the lack of contributed code than anything else.
> I am very glad that you are interested in collaboration with the
> interested developers.  WDYT, other people?  Does this sound good
> enough?  To get the collaboration started, we could start from the
> incubation proposal if there's no objection.  Stefano, I think you are
> most suitable person for writing the proposal in cooperation with
> Brian IMHO. :)

Are you talking about incubating "dnsjava" inside apache via incubator?

To follow this way we need Brian to provide a Software Grant for dnsjava
to the ASF, right? (Brian? are you willing to do that? Of course there
is no shame at all in not wanting to do this) Otherwise, can we incubate
a project based on BSD code without a software grant?

One of the main cause we are trying to start this effort is to create an
active community around the library and Brian told us that the main
problem from his is "lack of time", so we can't ask him too much in
terms of time, and I think we should tell him what exact actions we
expect from him and how much time this will take.

We know incubator is everything but a fast process ;-) and we don't want
to waste time a wrong direction.

I already saw many different opinions on what to do with this project,
so I think we should clearly understand who is interested and in what
roles (discussion only/ write code / test code / use the library).

As an example, if I understood correctly, Alex (dnsjnio/Nominet) is
interested in working on this shared effort only if the core will have
no external dependencies (read: no MINA), Julien Vermillard instead
already started working on the dns protocol in ADS that is almost the
opposite of what Alex has in his mind.

I'm currently trying to find a solution to make everyone happy and
really start creating a *community* and not a 2 people effort.

Assuming Alex and Brian accept this, IMO a good plan could be to start
from dnsjava+dnsjnio as this already provides full *working* synchronous
and asynchronous resolving library.
Then we can apply this refactorings:

1) Make the record types pluggable (currently to add a new supported
record type you have to change core dnsjava classes) programmatically
(we know at least 2 dnsjava forks have been started because of this
missing extensibility).

2) Split from-the-wire / to-the-wire code from the record classes.
2b) Refactor the code so we can start working side-by-site on a MINA
based protocol and on the currently working nio code (synchronous in
dnsjava and asynchronous in dnsjnio). Maybe MINA experts can help us
understanding how to better accomplish this without too much code

One thing we can also do is state our personal positions clearly. Here
is mine:
- I need an asynchronous SEDA based resolver easy to integrate in MINA
based protocol.
- I don't know DNS enough to start a full dns library from scratch
(read: I can't start from ADS dns protocol).
- I would like to have the new dnslibrary based on MINA, but I can live
also with a "custom" SEDA solution (like dnsjnio).
- My main interest is having dnsjava+dnsjnio features in a library
managed by a well known community (like ASF).
- what I'm willing to do: create code for simple dns testing,
refactoring to introduce more extension points and flexibility,
refactoring to better separate packages/layers of the library to make it
more simple to understand the code.
- I want to use this library at least in the Apache JAMES Server and
Apache jSPF products (so I would need this out of the incubator as soon
as possible as we can't do non-incubator releases based on incubator


View raw message