Stefano Bagnara wrote:
Trustin Lee wrote:
On 6/20/07, Brian Wellington <[EMAIL PROTECTED]> 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.
Maybe some of the changes I started to make to protocol-dns could help a
bit in this area. One of my goals was to try and make the
encoders/decoders completely independent of any MINA dependencies. So
if you look at the encoders/decoders at
http://svn.apache.org/viewvc/directory/apacheds/trunk/protocol-dns/src/main/java/org/apache/directory/server/dns/protocol/
you can see they are pretty thin wrappers around the encoders/decoders
that do the actual work which are at
http://svn.apache.org/viewvc/directory/apacheds/trunk/protocol-dns/src/main/java/org/apache/directory/server/dns/io/.
The only MINA class that those depend on is the MINA ByteBuffer which
provides handy utility methods that are really nice to have.
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
duplication.
That seems like a pretty reasonable approach to me. I think much of
what is in protocol-dns can be used as a basis for these refactorings.
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
releases).
----
Stefano
