[prev in list] [next in list] [prev in thread] [next in thread] 

List:       incubator-general
Subject:    Re: DNS Protocol (Was: DHCP Protocol Home)
From:       alexd () nominet ! org ! uk
Date:       2007-06-21 9:40:11
Message-ID: OF8E1C8203.8F962061-ON80257301.0031DD49-80257301.003519CA () nominet ! org ! uk
[Download RAW message or body]

Stefano Bagnara <apache@bago.org> wrote on 21/06/2007 09:47:21:

> 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
> duplication.

All this sounds fairly reasonable to me.

[One other change that is needed is that objects should be writable after 
instantiation. Currently, you can't decrease the TTL of a record, since 
you can't change the object. (Which was one of the reasons for the 
unbound-dnsjava fork)]

I think that there should be a well-accepted, stand-alone Java DNS library 
which depends on nothing but core Java classes. Not everyone who wants to 
use a DNS implementation will want to use MINA (or any other platform), so 
there should be no required dependencies. That's not to say that there 
shouldn't be a module which supports the use of MINA - it just shouldn't 
be *required*.

I also don't see any point in re-inventing any wheels. Dnsjava has had a 
lot of testing and use over the years, and presents a pretty complete 
standards-compliant DNS implementation. I see the way forward as being a 
refactoring of the library to allow greater flexibility.

If the point of the new effort is for there to be *one* Java DNS 
implementation, then it would seem sensible to me to strive to retain the 
existing dnsjava interface (in addition to extending and enhancing it). 
After all, we're going to want people with existing dnsjava code to take 
advantage of updates in the new code (e.g. NSEC3) without having to 
perform major refactoring.

I would certainly be happy to contribute the dnsjnio code to such an 
effort. We would also be happy to provide DNS expertise to the project, 
and would expect to be using the library for our own code. We would also 
be keen to add DNSSEC NSEC3 support to the code.

Thanks,


Alex.

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

[prev in list] [next in list] [prev in thread] [next in thread]