Re: DNS Protocol (Was: DHCP Protocol Home)

[Trustin Lee <tr...@gmail.com>]

On 6/12/07, Stefano Bagnara <ap...@bago.org> wrote:
> Trustin Lee ha scritto:
> > 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
> > it.
>
> For Apache JAMES jSPF library (http://james.apache.org/jspf/index.html)
> we're using a combination of a patched dnsjava and the trunk dnsjnio
> (http://sourceforge.net/projects/dnsjnio) library.
>
> We did this when moving to an asynchronous model for our SPF (DNS) lookups.
>
> As we currently depend on a "not-so-frequently-updated" (dnsjava)
> library (and we are waiting for bugs to be fixed) and on
> "not-so-widely-adopted" MPL licensed library (dnsjnio) I many times
> considered starting a MINA-DNS library based on core dnsjava tokens.
>
> I think that an asynchronous DNS library should be part of MINA core as
> many protocols require DNS lookups before connecting.
>
> Unfortunately I have limite knowledge of both the DNS protocol and MINA
> so I would like to help but I currently cannot afford the full project
> alone. If I had a guide between mina experts to help me with the main
> architecture I could try to start wiring up some code.
>
> Is anyone interested?

Unfortunately, I am not a DNS expert either.  We will give you as much
support as we can if you have any questions about MINA.  But it's not
free; you need to give us a rant whenever you find MINA sucks! ;)

It seems like we have three libraries on our table; dnsjava, dnsjnio,
and ADS DNS protocol provider.  The authors of all three libraries
could start to talk about getting the force together to form more
sustainable community.

I'll CC the authors of dnsjava and dnsjnio in case they are interested.

Trustin
-- 
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6

Re: DNS Protocol (Was: DHCP Protocol Home)

[Stefano Bagnara <ap...@bago.org>]

Richard Wallace ha scritto:
> 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.

About the decoder/encoder this seems to be the perfect solution.
But what about MINA handler/filters ?
In jSPF I introduced the concept of "continuation" so that every action
can do something and return a continuation. This way I don't care of who
will handle the real execution of the continuations: but now I don't
know how I could port this to MINA and if this is the best approach to
solve this "optional dependency" issue.

I think Alex is right when he tells that a light dns library should not
depend on anything but the JDK, but at the same time I think that MINA
can give us many tools (e.g: spring/jmx integration, throttle filters)
out of the box. Maybe MINA is more important on the server side than on
the client side.

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

This will take few more days/weeks to consolidate in our minds, but I
really think we can find a common goal and share the effort!

Thank you,
Stefano

Re: DNS Protocol (Was: DHCP Protocol Home)

[Richard Wallace <rw...@thewallacepack.net>]

Stefano Bagnara wrote:
> Trustin Lee wrote:
>   
>> On 6/20/07, Brian Wellington <bw...@xbill.org> 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
>
>   

Re: DNS Protocol (Was: DHCP Protocol Home)

[Trustin Lee <tr...@gmail.com>]

On 6/20/07, alexd@nominet.org.uk <al...@nominet.org.uk> wrote:
> "Trustin Lee" <tr...@gmail.com> wrote on 20/06/2007 09:32:44:
>
> > > > 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. :)
>
> I'm not sure I understand. Is the proposal to extend and evolve dnsjava,
> or is the proposal to create an entirely new DNS project?
>
> Personally, I'd favour a community-driven evolution of dnsjava if this was
> an option.

If I understood the general opinion in this thread, it was our first
try to extend and evolve dnsjava.  I guess everyone interested prefers
community-driven evolution of dnsjava.

Trustin
-- 
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6

Re: DNS Protocol (Was: DHCP Protocol Home)

[Trustin Lee <tr...@gmail.com>]

On 6/20/07, alexd@nominet.org.uk <al...@nominet.org.uk> wrote:
> "Trustin Lee" <tr...@gmail.com> wrote on 20/06/2007 09:32:44:
>
> > > > 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. :)
>
> I'm not sure I understand. Is the proposal to extend and evolve dnsjava,
> or is the proposal to create an entirely new DNS project?
>
> Personally, I'd favour a community-driven evolution of dnsjava if this was
> an option.

If I understood the general opinion in this thread, it was our first
try to extend and evolve dnsjava.  I guess everyone interested prefers
community-driven evolution of dnsjava.

Trustin
-- 
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6

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

Re: DNS Protocol (Was: DHCP Protocol Home)

[Trustin Lee <tr...@gmail.com>]

On 6/20/07, alexd@nominet.org.uk <al...@nominet.org.uk> wrote:
> "Trustin Lee" <tr...@gmail.com> wrote on 20/06/2007 09:32:44:
>
> > > > 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. :)
>
> I'm not sure I understand. Is the proposal to extend and evolve dnsjava,
> or is the proposal to create an entirely new DNS project?
>
> Personally, I'd favour a community-driven evolution of dnsjava if this was
> an option.

If I understood the general opinion in this thread, it was our first
try to extend and evolve dnsjava.  I guess everyone interested prefers
community-driven evolution of dnsjava.

Trustin
-- 
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6

Re: DNS Protocol (Was: DHCP Protocol Home)

[al...@nominet.org.uk]

"Trustin Lee" <tr...@gmail.com> wrote on 20/06/2007 09:32:44:

> > > 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. :)

I'm not sure I understand. Is the proposal to extend and evolve dnsjava, 
or is the proposal to create an entirely new DNS project?

Personally, I'd favour a community-driven evolution of dnsjava if this was 
an option.


Alex.

Re: DNS Protocol (Was: DHCP Protocol Home)

[al...@nominet.org.uk]

"Trustin Lee" <tr...@gmail.com> wrote on 20/06/2007 09:32:44:

> > > 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. :)

I'm not sure I understand. Is the proposal to extend and evolve dnsjava, 
or is the proposal to create an entirely new DNS project?

Personally, I'd favour a community-driven evolution of dnsjava if this was 
an option.


Alex.

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

Re: DNS Protocol (Was: DHCP Protocol Home)

[al...@nominet.org.uk]

> AFAIK the UNBOUND project solved the TTL issue by adding helpers
> ".withTTL(newTTL)" so to easily create record duplicates with only a
> different TTL and not by introducing mutators in the records.
> 
> We should be careful moving from an immutable object style to a mutable
> one. In fact the JVM is able to do big optimizations and multi threading
> is also much easier with immutable objects.

Undoubtedly so!!

The point is that there should be *some* means of doing this! The Unbound 
project forked in order to add this functionality.


Alex.

Re: DNS Protocol (Was: DHCP Protocol Home)

[Stefano Bagnara <ap...@bago.org>]

alexd@nominet.org.uk ha scritto:
> [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)]

Hi Alex,

This is probably one of the things to be discussed after we'll have
agreed on the high level direction, anyway I have a small consideration
to add.

AFAIK the UNBOUND project solved the TTL issue by adding helpers
".withTTL(newTTL)" so to easily create record duplicates with only a
different TTL and not by introducing mutators in the records.

We should be careful moving from an immutable object style to a mutable
one. In fact the JVM is able to do big optimizations and multi threading
is also much easier with immutable objects.

Stefano

PS: I removed some CC as this is a bit OT on other mailing lists and I
don't want to cross post 3 lists until we find (if we do) our new home :-)

Re: DNS Protocol (Was: DHCP Protocol Home)

[al...@nominet.org.uk]

Stefano Bagnara <ap...@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

Re: DNS Protocol (Was: DHCP Protocol Home)

[al...@nominet.org.uk]

Stefano Bagnara <ap...@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.

Re: DNS Protocol (Was: DHCP Protocol Home)

[al...@nominet.org.uk]

Stefano Bagnara <ap...@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.

Re: DNS Protocol (Was: DHCP Protocol Home)

[Stefano Bagnara <ap...@bago.org>]

Trustin Lee wrote:
> On 6/20/07, Brian Wellington <bw...@xbill.org> 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
duplication.

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

Re: DNS Protocol (Was: DHCP Protocol Home)

[Stefano Bagnara <ap...@bago.org>]

Trustin Lee wrote:
> On 6/20/07, Brian Wellington <bw...@xbill.org> 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
duplication.

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


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

Re: DNS Protocol (Was: DHCP Protocol Home)

[al...@nominet.org.uk]

"Trustin Lee" <tr...@gmail.com> wrote on 20/06/2007 09:32:44:

> > > 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. :)

I'm not sure I understand. Is the proposal to extend and evolve dnsjava, 
or is the proposal to create an entirely new DNS project?

Personally, I'd favour a community-driven evolution of dnsjava if this was 
an option.


Alex.

Re: DNS Protocol (Was: DHCP Protocol Home)

[Stefano Bagnara <ap...@bago.org>]

Trustin Lee wrote:
> On 6/20/07, Brian Wellington <bw...@xbill.org> 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
duplication.

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

Re: DNS Protocol (Was: DHCP Protocol Home)

[Trustin Lee <tr...@gmail.com>]

On 6/20/07, Brian Wellington <bw...@xbill.org> wrote:
<snip/>
> > The intent here is about build a community around DNS protocol
> > implementation.  I agree with you that dnsjava is a very mature and
> > stable product.  But there are also demand for asynchronous DNS
> > implementation.  dnsjnio is a good example, and some people want to
> > switch dnsjava's internal implementation with existing NIO framework
> > to fully utilize asynchronous API.  These changes will need quite a
> > lot of work and we thought dnsjava and dnsjnio are a great starting
> > point.  I'm not sure you have interest in these changes, but there are
> > about four guys who are interested in these changes, so we might be
> > able to create a nice community around it.  We also thought starting
> > this work in the ASF will be beneficial to many parties such as James,
> > MINA, and Directory project because they want to work closely with the
> > DNS protocol implementor in the near future (or right now).  Is your
> > question about our intent clarified?  WDYT?
>
> If there are enough people to form a community, then it sounds like a good
> idea.

<snip/>

> > 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. :)

<snip/>

> I'm not offended by this; I was trying to explain more than anything else.
> I know that dnsjava's been mostly inactive for a while now, which is a
> combination of my lack of time and the fact that there haven't been many
> things to add.

Thank you for your understanding!

Cheers,
Trustin
-- 
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6

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

Re: DNS Protocol (Was: DHCP Protocol Home)

[Trustin Lee <tr...@gmail.com>]

On 6/20/07, Brian Wellington <bw...@xbill.org> wrote:
<snip/>
> > The intent here is about build a community around DNS protocol
> > implementation.  I agree with you that dnsjava is a very mature and
> > stable product.  But there are also demand for asynchronous DNS
> > implementation.  dnsjnio is a good example, and some people want to
> > switch dnsjava's internal implementation with existing NIO framework
> > to fully utilize asynchronous API.  These changes will need quite a
> > lot of work and we thought dnsjava and dnsjnio are a great starting
> > point.  I'm not sure you have interest in these changes, but there are
> > about four guys who are interested in these changes, so we might be
> > able to create a nice community around it.  We also thought starting
> > this work in the ASF will be beneficial to many parties such as James,
> > MINA, and Directory project because they want to work closely with the
> > DNS protocol implementor in the near future (or right now).  Is your
> > question about our intent clarified?  WDYT?
>
> If there are enough people to form a community, then it sounds like a good
> idea.

<snip/>

> > 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. :)

<snip/>

> I'm not offended by this; I was trying to explain more than anything else.
> I know that dnsjava's been mostly inactive for a while now, which is a
> combination of my lack of time and the fact that there haven't been many
> things to add.

Thank you for your understanding!

Cheers,
Trustin
-- 
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6

Re: DNS Protocol (Was: DHCP Protocol Home)

[Trustin Lee <tr...@gmail.com>]

On 6/20/07, Brian Wellington <bw...@xbill.org> wrote:
<snip/>
> > The intent here is about build a community around DNS protocol
> > implementation.  I agree with you that dnsjava is a very mature and
> > stable product.  But there are also demand for asynchronous DNS
> > implementation.  dnsjnio is a good example, and some people want to
> > switch dnsjava's internal implementation with existing NIO framework
> > to fully utilize asynchronous API.  These changes will need quite a
> > lot of work and we thought dnsjava and dnsjnio are a great starting
> > point.  I'm not sure you have interest in these changes, but there are
> > about four guys who are interested in these changes, so we might be
> > able to create a nice community around it.  We also thought starting
> > this work in the ASF will be beneficial to many parties such as James,
> > MINA, and Directory project because they want to work closely with the
> > DNS protocol implementor in the near future (or right now).  Is your
> > question about our intent clarified?  WDYT?
>
> If there are enough people to form a community, then it sounds like a good
> idea.

<snip/>

> > 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. :)

<snip/>

> I'm not offended by this; I was trying to explain more than anything else.
> I know that dnsjava's been mostly inactive for a while now, which is a
> combination of my lack of time and the fact that there haven't been many
> things to add.

Thank you for your understanding!

Cheers,
Trustin
-- 
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6

Re: DNS Protocol (Was: DHCP Protocol Home)

[Brian Wellington <bw...@xbill.org>]

On Wed, 20 Jun 2007, Trustin Lee wrote:

> Hi Brian,
>
> On 6/20/07, Brian Wellington <bw...@xbill.org> wrote:
>> On Tue, 19 Jun 2007, Trustin Lee wrote:
>> 
>> > On 6/19/07, Stefano Bagnara <ap...@bago.org> wrote:
>> >> >> What if there were a "frequently updated" dnsjava, containing all of 
>> the
>> >> >> useful community-contributed patches (including dnsjnio), released
>> >> >> under a
>> >> >> BSD license - would that be a good solution?
>> >> >
>> >> > Absolutely.  That is the best of the best IMHO.  WDYT guys?
>> >>
>> >> Sorry but I don't understand the proposed scenario.
>> >>
>> >> I think the problem is that we need a community around a new dns project
>> >> because we want to provide fast respose and more evolution than dnsjava
>> >> currently offer.
>> >
>> > It is true if Brian doesn't have any will to work closely with us.
>> > He's not replying to us so far, so I agree with you.  And I don't
>> > think what Alex is suggesting to us is not so far from what we have
>> > been discussing.  He didn't say it should be outside of the ASF. ;)
>> 
>> To be honest, I'm not really sure what the intent here is.  For the past 5
>> years or so, there really hasn't been much need for much evolution or fast
>> response from dnsjava - there haven't been many features that I've wanted
>> to add, and there haven't been too many external patches.
>> 
>> The dnsjnio patch set is, as far as I know, the only code that should be
>> part of dnsjava but isn't.  That's mostly my fault - I haven't had much
>> time to work on dnsjava recently, and evaluating and working with a large
>> patch takes more time than I've had.
>
> The intent here is about build a community around DNS protocol
> implementation.  I agree with you that dnsjava is a very mature and
> stable product.  But there are also demand for asynchronous DNS
> implementation.  dnsjnio is a good example, and some people want to
> switch dnsjava's internal implementation with existing NIO framework
> to fully utilize asynchronous API.  These changes will need quite a
> lot of work and we thought dnsjava and dnsjnio are a great starting
> point.  I'm not sure you have interest in these changes, but there are
> about four guys who are interested in these changes, so we might be
> able to create a nice community around it.  We also thought starting
> this work in the ASF will be beneficial to many parties such as James,
> MINA, and Directory project because they want to work closely with the
> DNS protocol implementor in the near future (or right now).  Is your
> question about our intent clarified?  WDYT?

If there are enough people to form a community, then it sounds like a good 
idea.

>> >> What about the "frequently updated dnsjava" you talk about? Who will do
>> >> that? In what environment? What community? As it has been proposed to be
>> >> BSD then it cannot be hosted by ASF because the Apache Foundation will
>> >> only create/maintain ASLv2 projects (and will also need copyrights for
>> >> everything maintained).
>> >>
>> >> Indeed, I really would like to know whether Brian has objections to such
>> >> an effort, what would be his own preferences about dependencies (or
>> >> evolutions) of his code, if he would be interested in collaborating in a
>> >> more "community oriented" project, if he would be interested in an
>> >> oversight role.
>> 
>> If someone wants to fork dnsjava, I can't stop them.  A "community
>> oriented" project sounds like a good idea, but as I said above, there
>> really hasn't been much call for new features.  In the 8 years or so since
>> the first dnsjava release, there's only been 1 serious request for commit
>> access to the repository, which makes me wonder where the community is.
>> People occasionally pop up and ask for large features (some of which make
>> sense), but very infrequently contribute any code.
>> 
>> If the decision was made to fork or evolve the code, I wouldn't object,
>> but I don't know how much of a role I'd be willing to play.  I'm not using
>> dnsjava in any other large projects, so the only real development I do
>> (other than applying patches) is adding small features needed for
>> miscellaneous DNS testing and adding new record types.  The main reason I
>> use dnsjava for testing is that I know the API pretty well, and it's easy
>> for me to write code using it - if the API evolved to the point that
>> wasn't as familiar with it and my code didn't work, I'd probably continue
>> to use the old version or use something else (like dnspython - dnsjava and
>> small programs using it are the only java code I write anymore).
>
> 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.

>> > dnsjava is licensed under BSD-license, so we can fork it without prior
>> > permission, though we need to try.  (But he's not responding.)  And
>> > starting from the ADS DNS protocol provider is also a good idea.  I am
>> > not a DNS expert so it's up to the actual contributor of the project.
>> > If Alex is interested, it's a great news, and starting the project
>> > from the incubator might be a better idea to attract more interested
>> > non-committers such as Alex.  Even if we have little code base so far,
>> > we could discuss about this project with the incubator PMC and ask if
>> > we can start from existing code that we didn't write (dnsjava) due to
>> > its inactivity.
>> 
>> I can't really comment on this, as I don't know much about the ADS DNS
>> protocol provider.  Again, though, the "inactivity" you're referring to is
>> mostly the lack of any necessary changes.  dnsjava is pretty standards
>> compliant.  Other than a good asynchronous interface, there really isn't
>> anything that's missing.
>> 
>> Of course, the inactivity could be the lack of frequent releases to pick
>> up minor bug fixes.  I don't do releases more often because releasing
>> software on sourceforge is a pain (doing anything with the file release
>> system takes many times longer than it should), but the code in CVS (which
>> would have been moved to SVN a year ago if sourceforge's SVN conversion
>> scripts worked) should be pretty stable, if anyone would like to volunteer
>> to do more releases.
>
> I admit 'inactivity' here is incorrect and apologize from my heart if
> it dismays you.  Most of all, please consider our intent as serious
> will to improve the best-of-breed DNS implementation.

I'm not offended by this; I was trying to explain more than anything else. 
I know that dnsjava's been mostly inactive for a while now, which is a 
combination of my lack of time and the fact that there haven't been many 
things to add.

Brian

Re: DNS Protocol (Was: DHCP Protocol Home)

[Brian Wellington <bw...@xbill.org>]

On Wed, 20 Jun 2007, Trustin Lee wrote:

> Hi Brian,
>
> On 6/20/07, Brian Wellington <bw...@xbill.org> wrote:
>> On Tue, 19 Jun 2007, Trustin Lee wrote:
>> 
>> > On 6/19/07, Stefano Bagnara <ap...@bago.org> wrote:
>> >> >> What if there were a "frequently updated" dnsjava, containing all of 
>> the
>> >> >> useful community-contributed patches (including dnsjnio), released
>> >> >> under a
>> >> >> BSD license - would that be a good solution?
>> >> >
>> >> > Absolutely.  That is the best of the best IMHO.  WDYT guys?
>> >>
>> >> Sorry but I don't understand the proposed scenario.
>> >>
>> >> I think the problem is that we need a community around a new dns project
>> >> because we want to provide fast respose and more evolution than dnsjava
>> >> currently offer.
>> >
>> > It is true if Brian doesn't have any will to work closely with us.
>> > He's not replying to us so far, so I agree with you.  And I don't
>> > think what Alex is suggesting to us is not so far from what we have
>> > been discussing.  He didn't say it should be outside of the ASF. ;)
>> 
>> To be honest, I'm not really sure what the intent here is.  For the past 5
>> years or so, there really hasn't been much need for much evolution or fast
>> response from dnsjava - there haven't been many features that I've wanted
>> to add, and there haven't been too many external patches.
>> 
>> The dnsjnio patch set is, as far as I know, the only code that should be
>> part of dnsjava but isn't.  That's mostly my fault - I haven't had much
>> time to work on dnsjava recently, and evaluating and working with a large
>> patch takes more time than I've had.
>
> The intent here is about build a community around DNS protocol
> implementation.  I agree with you that dnsjava is a very mature and
> stable product.  But there are also demand for asynchronous DNS
> implementation.  dnsjnio is a good example, and some people want to
> switch dnsjava's internal implementation with existing NIO framework
> to fully utilize asynchronous API.  These changes will need quite a
> lot of work and we thought dnsjava and dnsjnio are a great starting
> point.  I'm not sure you have interest in these changes, but there are
> about four guys who are interested in these changes, so we might be
> able to create a nice community around it.  We also thought starting
> this work in the ASF will be beneficial to many parties such as James,
> MINA, and Directory project because they want to work closely with the
> DNS protocol implementor in the near future (or right now).  Is your
> question about our intent clarified?  WDYT?

If there are enough people to form a community, then it sounds like a good 
idea.

>> >> What about the "frequently updated dnsjava" you talk about? Who will do
>> >> that? In what environment? What community? As it has been proposed to be
>> >> BSD then it cannot be hosted by ASF because the Apache Foundation will
>> >> only create/maintain ASLv2 projects (and will also need copyrights for
>> >> everything maintained).
>> >>
>> >> Indeed, I really would like to know whether Brian has objections to such
>> >> an effort, what would be his own preferences about dependencies (or
>> >> evolutions) of his code, if he would be interested in collaborating in a
>> >> more "community oriented" project, if he would be interested in an
>> >> oversight role.
>> 
>> If someone wants to fork dnsjava, I can't stop them.  A "community
>> oriented" project sounds like a good idea, but as I said above, there
>> really hasn't been much call for new features.  In the 8 years or so since
>> the first dnsjava release, there's only been 1 serious request for commit
>> access to the repository, which makes me wonder where the community is.
>> People occasionally pop up and ask for large features (some of which make
>> sense), but very infrequently contribute any code.
>> 
>> If the decision was made to fork or evolve the code, I wouldn't object,
>> but I don't know how much of a role I'd be willing to play.  I'm not using
>> dnsjava in any other large projects, so the only real development I do
>> (other than applying patches) is adding small features needed for
>> miscellaneous DNS testing and adding new record types.  The main reason I
>> use dnsjava for testing is that I know the API pretty well, and it's easy
>> for me to write code using it - if the API evolved to the point that
>> wasn't as familiar with it and my code didn't work, I'd probably continue
>> to use the old version or use something else (like dnspython - dnsjava and
>> small programs using it are the only java code I write anymore).
>
> 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.

>> > dnsjava is licensed under BSD-license, so we can fork it without prior
>> > permission, though we need to try.  (But he's not responding.)  And
>> > starting from the ADS DNS protocol provider is also a good idea.  I am
>> > not a DNS expert so it's up to the actual contributor of the project.
>> > If Alex is interested, it's a great news, and starting the project
>> > from the incubator might be a better idea to attract more interested
>> > non-committers such as Alex.  Even if we have little code base so far,
>> > we could discuss about this project with the incubator PMC and ask if
>> > we can start from existing code that we didn't write (dnsjava) due to
>> > its inactivity.
>> 
>> I can't really comment on this, as I don't know much about the ADS DNS
>> protocol provider.  Again, though, the "inactivity" you're referring to is
>> mostly the lack of any necessary changes.  dnsjava is pretty standards
>> compliant.  Other than a good asynchronous interface, there really isn't
>> anything that's missing.
>> 
>> Of course, the inactivity could be the lack of frequent releases to pick
>> up minor bug fixes.  I don't do releases more often because releasing
>> software on sourceforge is a pain (doing anything with the file release
>> system takes many times longer than it should), but the code in CVS (which
>> would have been moved to SVN a year ago if sourceforge's SVN conversion
>> scripts worked) should be pretty stable, if anyone would like to volunteer
>> to do more releases.
>
> I admit 'inactivity' here is incorrect and apologize from my heart if
> it dismays you.  Most of all, please consider our intent as serious
> will to improve the best-of-breed DNS implementation.

I'm not offended by this; I was trying to explain more than anything else. 
I know that dnsjava's been mostly inactive for a while now, which is a 
combination of my lack of time and the fact that there haven't been many 
things to add.

Brian

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

Re: DNS Protocol (Was: DHCP Protocol Home)

[Trustin Lee <tr...@gmail.com>]

Hi Brian,

On 6/20/07, Brian Wellington <bw...@xbill.org> wrote:
> On Tue, 19 Jun 2007, Trustin Lee wrote:
>
> > On 6/19/07, Stefano Bagnara <ap...@bago.org> wrote:
> >> >> What if there were a "frequently updated" dnsjava, containing all of the
> >> >> useful community-contributed patches (including dnsjnio), released
> >> >> under a
> >> >> BSD license - would that be a good solution?
> >> >
> >> > Absolutely.  That is the best of the best IMHO.  WDYT guys?
> >>
> >> Sorry but I don't understand the proposed scenario.
> >>
> >> I think the problem is that we need a community around a new dns project
> >> because we want to provide fast respose and more evolution than dnsjava
> >> currently offer.
> >
> > It is true if Brian doesn't have any will to work closely with us.
> > He's not replying to us so far, so I agree with you.  And I don't
> > think what Alex is suggesting to us is not so far from what we have
> > been discussing.  He didn't say it should be outside of the ASF. ;)
>
> To be honest, I'm not really sure what the intent here is.  For the past 5
> years or so, there really hasn't been much need for much evolution or fast
> response from dnsjava - there haven't been many features that I've wanted
> to add, and there haven't been too many external patches.
>
> The dnsjnio patch set is, as far as I know, the only code that should be
> part of dnsjava but isn't.  That's mostly my fault - I haven't had much
> time to work on dnsjava recently, and evaluating and working with a large
> patch takes more time than I've had.

The intent here is about build a community around DNS protocol
implementation.  I agree with you that dnsjava is a very mature and
stable product.  But there are also demand for asynchronous DNS
implementation.  dnsjnio is a good example, and some people want to
switch dnsjava's internal implementation with existing NIO framework
to fully utilize asynchronous API.  These changes will need quite a
lot of work and we thought dnsjava and dnsjnio are a great starting
point.  I'm not sure you have interest in these changes, but there are
about four guys who are interested in these changes, so we might be
able to create a nice community around it.  We also thought starting
this work in the ASF will be beneficial to many parties such as James,
MINA, and Directory project because they want to work closely with the
DNS protocol implementor in the near future (or right now).  Is your
question about our intent clarified?  WDYT?

> >> What about the "frequently updated dnsjava" you talk about? Who will do
> >> that? In what environment? What community? As it has been proposed to be
> >> BSD then it cannot be hosted by ASF because the Apache Foundation will
> >> only create/maintain ASLv2 projects (and will also need copyrights for
> >> everything maintained).
> >>
> >> Indeed, I really would like to know whether Brian has objections to such
> >> an effort, what would be his own preferences about dependencies (or
> >> evolutions) of his code, if he would be interested in collaborating in a
> >> more "community oriented" project, if he would be interested in an
> >> oversight role.
>
> If someone wants to fork dnsjava, I can't stop them.  A "community
> oriented" project sounds like a good idea, but as I said above, there
> really hasn't been much call for new features.  In the 8 years or so since
> the first dnsjava release, there's only been 1 serious request for commit
> access to the repository, which makes me wonder where the community is.
> People occasionally pop up and ask for large features (some of which make
> sense), but very infrequently contribute any code.
>
> If the decision was made to fork or evolve the code, I wouldn't object,
> but I don't know how much of a role I'd be willing to play.  I'm not using
> dnsjava in any other large projects, so the only real development I do
> (other than applying patches) is adding small features needed for
> miscellaneous DNS testing and adding new record types.  The main reason I
> use dnsjava for testing is that I know the API pretty well, and it's easy
> for me to write code using it - if the API evolved to the point that
> wasn't as familiar with it and my code didn't work, I'd probably continue
> to use the old version or use something else (like dnspython - dnsjava and
> small programs using it are the only java code I write anymore).

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.

> > dnsjava is licensed under BSD-license, so we can fork it without prior
> > permission, though we need to try.  (But he's not responding.)  And
> > starting from the ADS DNS protocol provider is also a good idea.  I am
> > not a DNS expert so it's up to the actual contributor of the project.
> > If Alex is interested, it's a great news, and starting the project
> > from the incubator might be a better idea to attract more interested
> > non-committers such as Alex.  Even if we have little code base so far,
> > we could discuss about this project with the incubator PMC and ask if
> > we can start from existing code that we didn't write (dnsjava) due to
> > its inactivity.
>
> I can't really comment on this, as I don't know much about the ADS DNS
> protocol provider.  Again, though, the "inactivity" you're referring to is
> mostly the lack of any necessary changes.  dnsjava is pretty standards
> compliant.  Other than a good asynchronous interface, there really isn't
> anything that's missing.
>
> Of course, the inactivity could be the lack of frequent releases to pick
> up minor bug fixes.  I don't do releases more often because releasing
> software on sourceforge is a pain (doing anything with the file release
> system takes many times longer than it should), but the code in CVS (which
> would have been moved to SVN a year ago if sourceforge's SVN conversion
> scripts worked) should be pretty stable, if anyone would like to volunteer
> to do more releases.

I admit 'inactivity' here is incorrect and apologize from my heart if
it dismays you.  Most of all, please consider our intent as serious
will to improve the best-of-breed DNS implementation.

Thanks,
Trustin
-- 
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6

Re: DNS Protocol (Was: DHCP Protocol Home)

[Trustin Lee <tr...@gmail.com>]

Hi Brian,

On 6/20/07, Brian Wellington <bw...@xbill.org> wrote:
> On Tue, 19 Jun 2007, Trustin Lee wrote:
>
> > On 6/19/07, Stefano Bagnara <ap...@bago.org> wrote:
> >> >> What if there were a "frequently updated" dnsjava, containing all of the
> >> >> useful community-contributed patches (including dnsjnio), released
> >> >> under a
> >> >> BSD license - would that be a good solution?
> >> >
> >> > Absolutely.  That is the best of the best IMHO.  WDYT guys?
> >>
> >> Sorry but I don't understand the proposed scenario.
> >>
> >> I think the problem is that we need a community around a new dns project
> >> because we want to provide fast respose and more evolution than dnsjava
> >> currently offer.
> >
> > It is true if Brian doesn't have any will to work closely with us.
> > He's not replying to us so far, so I agree with you.  And I don't
> > think what Alex is suggesting to us is not so far from what we have
> > been discussing.  He didn't say it should be outside of the ASF. ;)
>
> To be honest, I'm not really sure what the intent here is.  For the past 5
> years or so, there really hasn't been much need for much evolution or fast
> response from dnsjava - there haven't been many features that I've wanted
> to add, and there haven't been too many external patches.
>
> The dnsjnio patch set is, as far as I know, the only code that should be
> part of dnsjava but isn't.  That's mostly my fault - I haven't had much
> time to work on dnsjava recently, and evaluating and working with a large
> patch takes more time than I've had.

The intent here is about build a community around DNS protocol
implementation.  I agree with you that dnsjava is a very mature and
stable product.  But there are also demand for asynchronous DNS
implementation.  dnsjnio is a good example, and some people want to
switch dnsjava's internal implementation with existing NIO framework
to fully utilize asynchronous API.  These changes will need quite a
lot of work and we thought dnsjava and dnsjnio are a great starting
point.  I'm not sure you have interest in these changes, but there are
about four guys who are interested in these changes, so we might be
able to create a nice community around it.  We also thought starting
this work in the ASF will be beneficial to many parties such as James,
MINA, and Directory project because they want to work closely with the
DNS protocol implementor in the near future (or right now).  Is your
question about our intent clarified?  WDYT?

> >> What about the "frequently updated dnsjava" you talk about? Who will do
> >> that? In what environment? What community? As it has been proposed to be
> >> BSD then it cannot be hosted by ASF because the Apache Foundation will
> >> only create/maintain ASLv2 projects (and will also need copyrights for
> >> everything maintained).
> >>
> >> Indeed, I really would like to know whether Brian has objections to such
> >> an effort, what would be his own preferences about dependencies (or
> >> evolutions) of his code, if he would be interested in collaborating in a
> >> more "community oriented" project, if he would be interested in an
> >> oversight role.
>
> If someone wants to fork dnsjava, I can't stop them.  A "community
> oriented" project sounds like a good idea, but as I said above, there
> really hasn't been much call for new features.  In the 8 years or so since
> the first dnsjava release, there's only been 1 serious request for commit
> access to the repository, which makes me wonder where the community is.
> People occasionally pop up and ask for large features (some of which make
> sense), but very infrequently contribute any code.
>
> If the decision was made to fork or evolve the code, I wouldn't object,
> but I don't know how much of a role I'd be willing to play.  I'm not using
> dnsjava in any other large projects, so the only real development I do
> (other than applying patches) is adding small features needed for
> miscellaneous DNS testing and adding new record types.  The main reason I
> use dnsjava for testing is that I know the API pretty well, and it's easy
> for me to write code using it - if the API evolved to the point that
> wasn't as familiar with it and my code didn't work, I'd probably continue
> to use the old version or use something else (like dnspython - dnsjava and
> small programs using it are the only java code I write anymore).

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.

> > dnsjava is licensed under BSD-license, so we can fork it without prior
> > permission, though we need to try.  (But he's not responding.)  And
> > starting from the ADS DNS protocol provider is also a good idea.  I am
> > not a DNS expert so it's up to the actual contributor of the project.
> > If Alex is interested, it's a great news, and starting the project
> > from the incubator might be a better idea to attract more interested
> > non-committers such as Alex.  Even if we have little code base so far,
> > we could discuss about this project with the incubator PMC and ask if
> > we can start from existing code that we didn't write (dnsjava) due to
> > its inactivity.
>
> I can't really comment on this, as I don't know much about the ADS DNS
> protocol provider.  Again, though, the "inactivity" you're referring to is
> mostly the lack of any necessary changes.  dnsjava is pretty standards
> compliant.  Other than a good asynchronous interface, there really isn't
> anything that's missing.
>
> Of course, the inactivity could be the lack of frequent releases to pick
> up minor bug fixes.  I don't do releases more often because releasing
> software on sourceforge is a pain (doing anything with the file release
> system takes many times longer than it should), but the code in CVS (which
> would have been moved to SVN a year ago if sourceforge's SVN conversion
> scripts worked) should be pretty stable, if anyone would like to volunteer
> to do more releases.

I admit 'inactivity' here is incorrect and apologize from my heart if
it dismays you.  Most of all, please consider our intent as serious
will to improve the best-of-breed DNS implementation.

Thanks,
Trustin
-- 
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6

Re: DNS Protocol (Was: DHCP Protocol Home)

[Trustin Lee <tr...@gmail.com>]

Hi Brian,

On 6/20/07, Brian Wellington <bw...@xbill.org> wrote:
> On Tue, 19 Jun 2007, Trustin Lee wrote:
>
> > On 6/19/07, Stefano Bagnara <ap...@bago.org> wrote:
> >> >> What if there were a "frequently updated" dnsjava, containing all of the
> >> >> useful community-contributed patches (including dnsjnio), released
> >> >> under a
> >> >> BSD license - would that be a good solution?
> >> >
> >> > Absolutely.  That is the best of the best IMHO.  WDYT guys?
> >>
> >> Sorry but I don't understand the proposed scenario.
> >>
> >> I think the problem is that we need a community around a new dns project
> >> because we want to provide fast respose and more evolution than dnsjava
> >> currently offer.
> >
> > It is true if Brian doesn't have any will to work closely with us.
> > He's not replying to us so far, so I agree with you.  And I don't
> > think what Alex is suggesting to us is not so far from what we have
> > been discussing.  He didn't say it should be outside of the ASF. ;)
>
> To be honest, I'm not really sure what the intent here is.  For the past 5
> years or so, there really hasn't been much need for much evolution or fast
> response from dnsjava - there haven't been many features that I've wanted
> to add, and there haven't been too many external patches.
>
> The dnsjnio patch set is, as far as I know, the only code that should be
> part of dnsjava but isn't.  That's mostly my fault - I haven't had much
> time to work on dnsjava recently, and evaluating and working with a large
> patch takes more time than I've had.

The intent here is about build a community around DNS protocol
implementation.  I agree with you that dnsjava is a very mature and
stable product.  But there are also demand for asynchronous DNS
implementation.  dnsjnio is a good example, and some people want to
switch dnsjava's internal implementation with existing NIO framework
to fully utilize asynchronous API.  These changes will need quite a
lot of work and we thought dnsjava and dnsjnio are a great starting
point.  I'm not sure you have interest in these changes, but there are
about four guys who are interested in these changes, so we might be
able to create a nice community around it.  We also thought starting
this work in the ASF will be beneficial to many parties such as James,
MINA, and Directory project because they want to work closely with the
DNS protocol implementor in the near future (or right now).  Is your
question about our intent clarified?  WDYT?

> >> What about the "frequently updated dnsjava" you talk about? Who will do
> >> that? In what environment? What community? As it has been proposed to be
> >> BSD then it cannot be hosted by ASF because the Apache Foundation will
> >> only create/maintain ASLv2 projects (and will also need copyrights for
> >> everything maintained).
> >>
> >> Indeed, I really would like to know whether Brian has objections to such
> >> an effort, what would be his own preferences about dependencies (or
> >> evolutions) of his code, if he would be interested in collaborating in a
> >> more "community oriented" project, if he would be interested in an
> >> oversight role.
>
> If someone wants to fork dnsjava, I can't stop them.  A "community
> oriented" project sounds like a good idea, but as I said above, there
> really hasn't been much call for new features.  In the 8 years or so since
> the first dnsjava release, there's only been 1 serious request for commit
> access to the repository, which makes me wonder where the community is.
> People occasionally pop up and ask for large features (some of which make
> sense), but very infrequently contribute any code.
>
> If the decision was made to fork or evolve the code, I wouldn't object,
> but I don't know how much of a role I'd be willing to play.  I'm not using
> dnsjava in any other large projects, so the only real development I do
> (other than applying patches) is adding small features needed for
> miscellaneous DNS testing and adding new record types.  The main reason I
> use dnsjava for testing is that I know the API pretty well, and it's easy
> for me to write code using it - if the API evolved to the point that
> wasn't as familiar with it and my code didn't work, I'd probably continue
> to use the old version or use something else (like dnspython - dnsjava and
> small programs using it are the only java code I write anymore).

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.

> > dnsjava is licensed under BSD-license, so we can fork it without prior
> > permission, though we need to try.  (But he's not responding.)  And
> > starting from the ADS DNS protocol provider is also a good idea.  I am
> > not a DNS expert so it's up to the actual contributor of the project.
> > If Alex is interested, it's a great news, and starting the project
> > from the incubator might be a better idea to attract more interested
> > non-committers such as Alex.  Even if we have little code base so far,
> > we could discuss about this project with the incubator PMC and ask if
> > we can start from existing code that we didn't write (dnsjava) due to
> > its inactivity.
>
> I can't really comment on this, as I don't know much about the ADS DNS
> protocol provider.  Again, though, the "inactivity" you're referring to is
> mostly the lack of any necessary changes.  dnsjava is pretty standards
> compliant.  Other than a good asynchronous interface, there really isn't
> anything that's missing.
>
> Of course, the inactivity could be the lack of frequent releases to pick
> up minor bug fixes.  I don't do releases more often because releasing
> software on sourceforge is a pain (doing anything with the file release
> system takes many times longer than it should), but the code in CVS (which
> would have been moved to SVN a year ago if sourceforge's SVN conversion
> scripts worked) should be pretty stable, if anyone would like to volunteer
> to do more releases.

I admit 'inactivity' here is incorrect and apologize from my heart if
it dismays you.  Most of all, please consider our intent as serious
will to improve the best-of-breed DNS implementation.

Thanks,
Trustin
-- 
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6

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

Re: DNS Protocol (Was: DHCP Protocol Home)

[Brian Wellington <bw...@xbill.org>]

On Tue, 19 Jun 2007, Trustin Lee wrote:

> On 6/19/07, Stefano Bagnara <ap...@bago.org> wrote:
>> >> What if there were a "frequently updated" dnsjava, containing all of the
>> >> useful community-contributed patches (including dnsjnio), released
>> >> under a
>> >> BSD license - would that be a good solution?
>> >
>> > Absolutely.  That is the best of the best IMHO.  WDYT guys?
>> 
>> Sorry but I don't understand the proposed scenario.
>> 
>> I think the problem is that we need a community around a new dns project
>> because we want to provide fast respose and more evolution than dnsjava
>> currently offer.
>
> It is true if Brian doesn't have any will to work closely with us.
> He's not replying to us so far, so I agree with you.  And I don't
> think what Alex is suggesting to us is not so far from what we have
> been discussing.  He didn't say it should be outside of the ASF. ;)

To be honest, I'm not really sure what the intent here is.  For the past 5 
years or so, there really hasn't been much need for much evolution or fast 
response from dnsjava - there haven't been many features that I've wanted 
to add, and there haven't been too many external patches.

The dnsjnio patch set is, as far as I know, the only code that should be 
part of dnsjava but isn't.  That's mostly my fault - I haven't had much 
time to work on dnsjava recently, and evaluating and working with a large 
patch takes more time than I've had.

>> What about the "frequently updated dnsjava" you talk about? Who will do
>> that? In what environment? What community? As it has been proposed to be
>> BSD then it cannot be hosted by ASF because the Apache Foundation will
>> only create/maintain ASLv2 projects (and will also need copyrights for
>> everything maintained).
>> 
>> Indeed, I really would like to know whether Brian has objections to such
>> an effort, what would be his own preferences about dependencies (or
>> evolutions) of his code, if he would be interested in collaborating in a
>> more "community oriented" project, if he would be interested in an
>> oversight role.

If someone wants to fork dnsjava, I can't stop them.  A "community 
oriented" project sounds like a good idea, but as I said above, there 
really hasn't been much call for new features.  In the 8 years or so since 
the first dnsjava release, there's only been 1 serious request for commit 
access to the repository, which makes me wonder where the community is. 
People occasionally pop up and ask for large features (some of which make 
sense), but very infrequently contribute any code.

If the decision was made to fork or evolve the code, I wouldn't object, 
but I don't know how much of a role I'd be willing to play.  I'm not using 
dnsjava in any other large projects, so the only real development I do 
(other than applying patches) is adding small features needed for 
miscellaneous DNS testing and adding new record types.  The main reason I 
use dnsjava for testing is that I know the API pretty well, and it's easy 
for me to write code using it - if the API evolved to the point that 
wasn't as familiar with it and my code didn't work, I'd probably continue 
to use the old version or use something else (like dnspython - dnsjava and 
small programs using it are the only java code I write anymore).

> dnsjava is licensed under BSD-license, so we can fork it without prior
> permission, though we need to try.  (But he's not responding.)  And
> starting from the ADS DNS protocol provider is also a good idea.  I am
> not a DNS expert so it's up to the actual contributor of the project.
> If Alex is interested, it's a great news, and starting the project
> from the incubator might be a better idea to attract more interested
> non-committers such as Alex.  Even if we have little code base so far,
> we could discuss about this project with the incubator PMC and ask if
> we can start from existing code that we didn't write (dnsjava) due to
> its inactivity.

I can't really comment on this, as I don't know much about the ADS DNS 
protocol provider.  Again, though, the "inactivity" you're referring to is 
mostly the lack of any necessary changes.  dnsjava is pretty standards 
compliant.  Other than a good asynchronous interface, there really isn't 
anything that's missing.

Of course, the inactivity could be the lack of frequent releases to pick 
up minor bug fixes.  I don't do releases more often because releasing 
software on sourceforge is a pain (doing anything with the file release 
system takes many times longer than it should), but the code in CVS (which 
would have been moved to SVN a year ago if sourceforge's SVN conversion 
scripts worked) should be pretty stable, if anyone would like to volunteer 
to do more releases.

Brian

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

Re: DNS Protocol (Was: DHCP Protocol Home)

[Brian Wellington <bw...@xbill.org>]

On Tue, 19 Jun 2007, Trustin Lee wrote:

> On 6/19/07, Stefano Bagnara <ap...@bago.org> wrote:
>> >> What if there were a "frequently updated" dnsjava, containing all of the
>> >> useful community-contributed patches (including dnsjnio), released
>> >> under a
>> >> BSD license - would that be a good solution?
>> >
>> > Absolutely.  That is the best of the best IMHO.  WDYT guys?
>> 
>> Sorry but I don't understand the proposed scenario.
>> 
>> I think the problem is that we need a community around a new dns project
>> because we want to provide fast respose and more evolution than dnsjava
>> currently offer.
>
> It is true if Brian doesn't have any will to work closely with us.
> He's not replying to us so far, so I agree with you.  And I don't
> think what Alex is suggesting to us is not so far from what we have
> been discussing.  He didn't say it should be outside of the ASF. ;)

To be honest, I'm not really sure what the intent here is.  For the past 5 
years or so, there really hasn't been much need for much evolution or fast 
response from dnsjava - there haven't been many features that I've wanted 
to add, and there haven't been too many external patches.

The dnsjnio patch set is, as far as I know, the only code that should be 
part of dnsjava but isn't.  That's mostly my fault - I haven't had much 
time to work on dnsjava recently, and evaluating and working with a large 
patch takes more time than I've had.

>> What about the "frequently updated dnsjava" you talk about? Who will do
>> that? In what environment? What community? As it has been proposed to be
>> BSD then it cannot be hosted by ASF because the Apache Foundation will
>> only create/maintain ASLv2 projects (and will also need copyrights for
>> everything maintained).
>> 
>> Indeed, I really would like to know whether Brian has objections to such
>> an effort, what would be his own preferences about dependencies (or
>> evolutions) of his code, if he would be interested in collaborating in a
>> more "community oriented" project, if he would be interested in an
>> oversight role.

If someone wants to fork dnsjava, I can't stop them.  A "community 
oriented" project sounds like a good idea, but as I said above, there 
really hasn't been much call for new features.  In the 8 years or so since 
the first dnsjava release, there's only been 1 serious request for commit 
access to the repository, which makes me wonder where the community is. 
People occasionally pop up and ask for large features (some of which make 
sense), but very infrequently contribute any code.

If the decision was made to fork or evolve the code, I wouldn't object, 
but I don't know how much of a role I'd be willing to play.  I'm not using 
dnsjava in any other large projects, so the only real development I do 
(other than applying patches) is adding small features needed for 
miscellaneous DNS testing and adding new record types.  The main reason I 
use dnsjava for testing is that I know the API pretty well, and it's easy 
for me to write code using it - if the API evolved to the point that 
wasn't as familiar with it and my code didn't work, I'd probably continue 
to use the old version or use something else (like dnspython - dnsjava and 
small programs using it are the only java code I write anymore).

> dnsjava is licensed under BSD-license, so we can fork it without prior
> permission, though we need to try.  (But he's not responding.)  And
> starting from the ADS DNS protocol provider is also a good idea.  I am
> not a DNS expert so it's up to the actual contributor of the project.
> If Alex is interested, it's a great news, and starting the project
> from the incubator might be a better idea to attract more interested
> non-committers such as Alex.  Even if we have little code base so far,
> we could discuss about this project with the incubator PMC and ask if
> we can start from existing code that we didn't write (dnsjava) due to
> its inactivity.

I can't really comment on this, as I don't know much about the ADS DNS 
protocol provider.  Again, though, the "inactivity" you're referring to is 
mostly the lack of any necessary changes.  dnsjava is pretty standards 
compliant.  Other than a good asynchronous interface, there really isn't 
anything that's missing.

Of course, the inactivity could be the lack of frequent releases to pick 
up minor bug fixes.  I don't do releases more often because releasing 
software on sourceforge is a pain (doing anything with the file release 
system takes many times longer than it should), but the code in CVS (which 
would have been moved to SVN a year ago if sourceforge's SVN conversion 
scripts worked) should be pretty stable, if anyone would like to volunteer 
to do more releases.

Brian

Re: DNS Protocol (Was: DHCP Protocol Home)

[Trustin Lee <tr...@gmail.com>]

On 6/19/07, Stefano Bagnara <ap...@bago.org> wrote:
> >> What if there were a "frequently updated" dnsjava, containing all of the
> >> useful community-contributed patches (including dnsjnio), released
> >> under a
> >> BSD license - would that be a good solution?
> >
> > Absolutely.  That is the best of the best IMHO.  WDYT guys?
>
> Sorry but I don't understand the proposed scenario.
>
> I think the problem is that we need a community around a new dns project
> because we want to provide fast respose and more evolution than dnsjava
> currently offer.

It is true if Brian doesn't have any will to work closely with us.
He's not replying to us so far, so I agree with you.  And I don't
think what Alex is suggesting to us is not so far from what we have
been discussing.  He didn't say it should be outside of the ASF. ;)

<snip/>

> What about the "frequently updated dnsjava" you talk about? Who will do
> that? In what environment? What community? As it has been proposed to be
> BSD then it cannot be hosted by ASF because the Apache Foundation will
> only create/maintain ASLv2 projects (and will also need copyrights for
> everything maintained).
>
> Indeed, I really would like to know whether Brian has objections to such
> an effort, what would be his own preferences about dependencies (or
> evolutions) of his code, if he would be interested in collaborating in a
> more "community oriented" project, if he would be interested in an
> oversight role.

dnsjava is licensed under BSD-license, so we can fork it without prior
permission, though we need to try.  (But he's not responding.)  And
starting from the ADS DNS protocol provider is also a good idea.  I am
not a DNS expert so it's up to the actual contributor of the project.
If Alex is interested, it's a great news, and starting the project
from the incubator might be a better idea to attract more interested
non-committers such as Alex.  Even if we have little code base so far,
we could discuss about this project with the incubator PMC and ask if
we can start from existing code that we didn't write (dnsjava) due to
its inactivity.

BTW, MINA PMC needs to discuss about hosting the project again because
we are split into two opinions; to host it at Lab or under MINA.
These two options got the same vote count, so I have no idea what to
do right now.  I started to think it's better to discuss first with
the incubator PMC.

Let me CC general@incubator.a.o to find out what people think about it.

The whole thread can be browsed here:

http://www.mail-archive.com/dev@mina.apache.org/msg02835.html

Trustin
-- 
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6

Re: DNS Protocol (Was: DHCP Protocol Home)

[Trustin Lee <tr...@gmail.com>]

On 6/19/07, Stefano Bagnara <ap...@bago.org> wrote:
> >> What if there were a "frequently updated" dnsjava, containing all of the
> >> useful community-contributed patches (including dnsjnio), released
> >> under a
> >> BSD license - would that be a good solution?
> >
> > Absolutely.  That is the best of the best IMHO.  WDYT guys?
>
> Sorry but I don't understand the proposed scenario.
>
> I think the problem is that we need a community around a new dns project
> because we want to provide fast respose and more evolution than dnsjava
> currently offer.

It is true if Brian doesn't have any will to work closely with us.
He's not replying to us so far, so I agree with you.  And I don't
think what Alex is suggesting to us is not so far from what we have
been discussing.  He didn't say it should be outside of the ASF. ;)

<snip/>

> What about the "frequently updated dnsjava" you talk about? Who will do
> that? In what environment? What community? As it has been proposed to be
> BSD then it cannot be hosted by ASF because the Apache Foundation will
> only create/maintain ASLv2 projects (and will also need copyrights for
> everything maintained).
>
> Indeed, I really would like to know whether Brian has objections to such
> an effort, what would be his own preferences about dependencies (or
> evolutions) of his code, if he would be interested in collaborating in a
> more "community oriented" project, if he would be interested in an
> oversight role.

dnsjava is licensed under BSD-license, so we can fork it without prior
permission, though we need to try.  (But he's not responding.)  And
starting from the ADS DNS protocol provider is also a good idea.  I am
not a DNS expert so it's up to the actual contributor of the project.
If Alex is interested, it's a great news, and starting the project
from the incubator might be a better idea to attract more interested
non-committers such as Alex.  Even if we have little code base so far,
we could discuss about this project with the incubator PMC and ask if
we can start from existing code that we didn't write (dnsjava) due to
its inactivity.

BTW, MINA PMC needs to discuss about hosting the project again because
we are split into two opinions; to host it at Lab or under MINA.
These two options got the same vote count, so I have no idea what to
do right now.  I started to think it's better to discuss first with
the incubator PMC.

Let me CC general@incubator.a.o to find out what people think about it.

The whole thread can be browsed here:

http://www.mail-archive.com/dev@mina.apache.org/msg02835.html

Trustin
-- 
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6

Re: DNS Protocol (Was: DHCP Protocol Home)

[Trustin Lee <tr...@gmail.com>]

On 6/19/07, Stefano Bagnara <ap...@bago.org> wrote:
> >> What if there were a "frequently updated" dnsjava, containing all of the
> >> useful community-contributed patches (including dnsjnio), released
> >> under a
> >> BSD license - would that be a good solution?
> >
> > Absolutely.  That is the best of the best IMHO.  WDYT guys?
>
> Sorry but I don't understand the proposed scenario.
>
> I think the problem is that we need a community around a new dns project
> because we want to provide fast respose and more evolution than dnsjava
> currently offer.

It is true if Brian doesn't have any will to work closely with us.
He's not replying to us so far, so I agree with you.  And I don't
think what Alex is suggesting to us is not so far from what we have
been discussing.  He didn't say it should be outside of the ASF. ;)

<snip/>

> What about the "frequently updated dnsjava" you talk about? Who will do
> that? In what environment? What community? As it has been proposed to be
> BSD then it cannot be hosted by ASF because the Apache Foundation will
> only create/maintain ASLv2 projects (and will also need copyrights for
> everything maintained).
>
> Indeed, I really would like to know whether Brian has objections to such
> an effort, what would be his own preferences about dependencies (or
> evolutions) of his code, if he would be interested in collaborating in a
> more "community oriented" project, if he would be interested in an
> oversight role.

dnsjava is licensed under BSD-license, so we can fork it without prior
permission, though we need to try.  (But he's not responding.)  And
starting from the ADS DNS protocol provider is also a good idea.  I am
not a DNS expert so it's up to the actual contributor of the project.
If Alex is interested, it's a great news, and starting the project
from the incubator might be a better idea to attract more interested
non-committers such as Alex.  Even if we have little code base so far,
we could discuss about this project with the incubator PMC and ask if
we can start from existing code that we didn't write (dnsjava) due to
its inactivity.

BTW, MINA PMC needs to discuss about hosting the project again because
we are split into two opinions; to host it at Lab or under MINA.
These two options got the same vote count, so I have no idea what to
do right now.  I started to think it's better to discuss first with
the incubator PMC.

Let me CC general@incubator.a.o to find out what people think about it.

The whole thread can be browsed here:

http://www.mail-archive.com/dev@mina.apache.org/msg02835.html

Trustin
-- 
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6

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

Re: DNS Protocol (Was: DHCP Protocol Home)

[Julien Vermillard <jv...@archean.fr>]

On Tue, 19 Jun 2007 09:27:56 +0200
Stefano Bagnara <ap...@bago.org> wrote:

> Trustin Lee ha scritto:
> > On 6/18/07, alexd@nominet.org.uk <al...@nominet.org.uk> wrote:
> >> Hi -
> >>
> >> I'm sorry for the delay in replying - I've just returned from
> >> holiday.
> >>
> >> "Trustin Lee" <tr...@gmail.com> wrote on 12/06/2007 16:02:06:
> >>
> >> > > As we currently depend on a
> >> > > "not-so-frequently-updated" (dnsjava) library (and we are
> >> > > waiting for bugs to be fixed) and on "not-so-widely-adopted"
> >> > > MPL licensed library (dnsjnio) I many times considered
> >> > > starting a MINA-DNS library based on core dnsjava tokens.
> >> >
> >> > It seems like we have three libraries on our table; dnsjava,
> >> > dnsjnio, and ADS DNS protocol provider.  The authors of all
> >> > three libraries could start to talk about getting the force
> >> > together to form more sustainable community.
> >> >
> >> > I'll CC the authors of dnsjava and dnsjnio in case they are
> >> > interested.
> >>
> >> What if there were a "frequently updated" dnsjava, containing all
> >> of the useful community-contributed patches (including dnsjnio),
> >> released under a
> >> BSD license - would that be a good solution?
> > 
> > Absolutely.  That is the best of the best IMHO.  WDYT guys?
> > 
> > Trustin
> 
> Sorry but I don't understand the proposed scenario.
> 
> I think the problem is that we need a community around a new dns
> project because we want to provide fast respose and more evolution
> than dnsjava currently offer.
> 
> Please note that I have nothing against Brian Wellington that indeed
> have done a great work during all the past years developing and
> maintaining the great dnsjava library.
> 
> So what I think we need is a community that can provide that effort
> and can do this for the next years: maybe the ASF can be such a place.
> 
> What about the "frequently updated dnsjava" you talk about? Who will
> do that? In what environment? What community? As it has been proposed
> to be BSD then it cannot be hosted by ASF because the Apache
> Foundation will only create/maintain ASLv2 projects (and will also
> need copyrights for everything maintained).
> 
> Indeed, I really would like to know whether Brian has objections to
> such an effort, what would be his own preferences about dependencies
> (or evolutions) of his code, if he would be interested in
> collaborating in a more "community oriented" project, if he would be
> interested in an oversight role.
> 
> Stefano
> 

Hi,

I'm currently trying the ADS DNS server and the code is quite simple
and MINA based (read "ByteBuffer" and "asynchronous" here :D ). I
patched it for making it totaly independent of other ADS code, and it
was quite trivial. Writing a client based on this codec is probably
trivial too. Perhaps dnsjava got more
functionality, but the code structure for encoding/decoding
data-typestart to look old ( http://tinyurl.com/2pgyeg ) and the whole
network stack is based bio (you got a patch for using NIO, but nothing
for use MINA). It's ASLv2 licensed, already incubated and ADS team
prolly happy to receive new patch and new supported data-types coming
from dnsjava and will sure like to created a separated project if they
are flooded, like they was with MINA ;)

Julien

Re: DNS Protocol (Was: DHCP Protocol Home)

[Stefano Bagnara <ap...@bago.org>]

Trustin Lee ha scritto:
> On 6/18/07, alexd@nominet.org.uk <al...@nominet.org.uk> wrote:
>> Hi -
>>
>> I'm sorry for the delay in replying - I've just returned from holiday.
>>
>> "Trustin Lee" <tr...@gmail.com> wrote on 12/06/2007 16:02:06:
>>
>> > > As we currently depend on a "not-so-frequently-updated" (dnsjava)
>> > > library (and we are waiting for bugs to be fixed) and on
>> > > "not-so-widely-adopted" MPL licensed library (dnsjnio) I many times
>> > > considered starting a MINA-DNS library based on core dnsjava tokens.
>> >
>> > It seems like we have three libraries on our table; dnsjava, dnsjnio,
>> > and ADS DNS protocol provider.  The authors of all three libraries
>> > could start to talk about getting the force together to form more
>> > sustainable community.
>> >
>> > I'll CC the authors of dnsjava and dnsjnio in case they are interested.
>>
>> What if there were a "frequently updated" dnsjava, containing all of the
>> useful community-contributed patches (including dnsjnio), released
>> under a
>> BSD license - would that be a good solution?
> 
> Absolutely.  That is the best of the best IMHO.  WDYT guys?
> 
> Trustin

Sorry but I don't understand the proposed scenario.

I think the problem is that we need a community around a new dns project
because we want to provide fast respose and more evolution than dnsjava
currently offer.

Please note that I have nothing against Brian Wellington that indeed
have done a great work during all the past years developing and
maintaining the great dnsjava library.

So what I think we need is a community that can provide that effort and
can do this for the next years: maybe the ASF can be such a place.

What about the "frequently updated dnsjava" you talk about? Who will do
that? In what environment? What community? As it has been proposed to be
BSD then it cannot be hosted by ASF because the Apache Foundation will
only create/maintain ASLv2 projects (and will also need copyrights for
everything maintained).

Indeed, I really would like to know whether Brian has objections to such
an effort, what would be his own preferences about dependencies (or
evolutions) of his code, if he would be interested in collaborating in a
more "community oriented" project, if he would be interested in an
oversight role.

Stefano

Re: DNS Protocol (Was: DHCP Protocol Home)

[Stefano Bagnara <ap...@bago.org>]

Trustin Lee ha scritto:
> On 6/18/07, alexd@nominet.org.uk <al...@nominet.org.uk> wrote:
>> Hi -
>>
>> I'm sorry for the delay in replying - I've just returned from holiday.
>>
>> "Trustin Lee" <tr...@gmail.com> wrote on 12/06/2007 16:02:06:
>>
>> > > As we currently depend on a "not-so-frequently-updated" (dnsjava)
>> > > library (and we are waiting for bugs to be fixed) and on
>> > > "not-so-widely-adopted" MPL licensed library (dnsjnio) I many times
>> > > considered starting a MINA-DNS library based on core dnsjava tokens.
>> >
>> > It seems like we have three libraries on our table; dnsjava, dnsjnio,
>> > and ADS DNS protocol provider.  The authors of all three libraries
>> > could start to talk about getting the force together to form more
>> > sustainable community.
>> >
>> > I'll CC the authors of dnsjava and dnsjnio in case they are interested.
>>
>> What if there were a "frequently updated" dnsjava, containing all of the
>> useful community-contributed patches (including dnsjnio), released
>> under a
>> BSD license - would that be a good solution?
> 
> Absolutely.  That is the best of the best IMHO.  WDYT guys?
> 
> Trustin

Sorry but I don't understand the proposed scenario.

I think the problem is that we need a community around a new dns project
because we want to provide fast respose and more evolution than dnsjava
currently offer.

Please note that I have nothing against Brian Wellington that indeed
have done a great work during all the past years developing and
maintaining the great dnsjava library.

So what I think we need is a community that can provide that effort and
can do this for the next years: maybe the ASF can be such a place.

What about the "frequently updated dnsjava" you talk about? Who will do
that? In what environment? What community? As it has been proposed to be
BSD then it cannot be hosted by ASF because the Apache Foundation will
only create/maintain ASLv2 projects (and will also need copyrights for
everything maintained).

Indeed, I really would like to know whether Brian has objections to such
an effort, what would be his own preferences about dependencies (or
evolutions) of his code, if he would be interested in collaborating in a
more "community oriented" project, if he would be interested in an
oversight role.

Stefano

Re: DNS Protocol (Was: DHCP Protocol Home)

[Trustin Lee <tr...@gmail.com>]

On 6/18/07, alexd@nominet.org.uk <al...@nominet.org.uk> wrote:
> Hi -
>
> I'm sorry for the delay in replying - I've just returned from holiday.
>
> "Trustin Lee" <tr...@gmail.com> wrote on 12/06/2007 16:02:06:
>
> > > As we currently depend on a "not-so-frequently-updated" (dnsjava)
> > > library (and we are waiting for bugs to be fixed) and on
> > > "not-so-widely-adopted" MPL licensed library (dnsjnio) I many times
> > > considered starting a MINA-DNS library based on core dnsjava tokens.
> >
> > It seems like we have three libraries on our table; dnsjava, dnsjnio,
> > and ADS DNS protocol provider.  The authors of all three libraries
> > could start to talk about getting the force together to form more
> > sustainable community.
> >
> > I'll CC the authors of dnsjava and dnsjnio in case they are interested.
>
> What if there were a "frequently updated" dnsjava, containing all of the
> useful community-contributed patches (including dnsjnio), released under a
> BSD license - would that be a good solution?

Absolutely.  That is the best of the best IMHO.  WDYT guys?

Trustin
-- 
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6

Re: DNS Protocol (Was: DHCP Protocol Home)

[Trustin Lee <tr...@gmail.com>]

On 6/18/07, alexd@nominet.org.uk <al...@nominet.org.uk> wrote:
> Hi -
>
> I'm sorry for the delay in replying - I've just returned from holiday.
>
> "Trustin Lee" <tr...@gmail.com> wrote on 12/06/2007 16:02:06:
>
> > > As we currently depend on a "not-so-frequently-updated" (dnsjava)
> > > library (and we are waiting for bugs to be fixed) and on
> > > "not-so-widely-adopted" MPL licensed library (dnsjnio) I many times
> > > considered starting a MINA-DNS library based on core dnsjava tokens.
> >
> > It seems like we have three libraries on our table; dnsjava, dnsjnio,
> > and ADS DNS protocol provider.  The authors of all three libraries
> > could start to talk about getting the force together to form more
> > sustainable community.
> >
> > I'll CC the authors of dnsjava and dnsjnio in case they are interested.
>
> What if there were a "frequently updated" dnsjava, containing all of the
> useful community-contributed patches (including dnsjnio), released under a
> BSD license - would that be a good solution?

Absolutely.  That is the best of the best IMHO.  WDYT guys?

Trustin
-- 
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6

Re: DNS Protocol (Was: DHCP Protocol Home)

[al...@nominet.org.uk]

Hi - 

I'm sorry for the delay in replying - I've just returned from holiday.

"Trustin Lee" <tr...@gmail.com> wrote on 12/06/2007 16:02:06:

> > As we currently depend on a "not-so-frequently-updated" (dnsjava)
> > library (and we are waiting for bugs to be fixed) and on
> > "not-so-widely-adopted" MPL licensed library (dnsjnio) I many times
> > considered starting a MINA-DNS library based on core dnsjava tokens.
> 
> It seems like we have three libraries on our table; dnsjava, dnsjnio,
> and ADS DNS protocol provider.  The authors of all three libraries
> could start to talk about getting the force together to form more
> sustainable community.
> 
> I'll CC the authors of dnsjava and dnsjnio in case they are interested.

What if there were a "frequently updated" dnsjava, containing all of the 
useful community-contributed patches (including dnsjnio), released under a 
BSD license - would that be a good solution?

Thanks,


Alex.

Re: DNS Protocol (Was: DHCP Protocol Home)

[Norman <no...@apache.org>]

Stefano Bagnara schrieb:
> Trustin Lee ha scritto:
>   
>> Unfortunately, I am not a DNS expert either.  We will give you as much
>> support as we can if you have any questions about MINA.  But it's not
>> free; you need to give us a rant whenever you find MINA sucks! ;)
>>
>> It seems like we have three libraries on our table; dnsjava, dnsjnio,
>> and ADS DNS protocol provider.  The authors of all three libraries
>> could start to talk about getting the force together to form more
>> sustainable community.
>>
>> I'll CC the authors of dnsjava and dnsjnio in case they are interested.
>>     
>
> I had conversations with both authors in past.
>
> Alex (author of dnsjnio) already contacted Brian (author of dnsjava)
> about extending dnsjava for asynchronous operations but Brian lately is
> much less active on dnsjava and only applies few bug fixes every few
> months (well, in fact I have also reported 2 really small, but critical
> to me, bugs a while ago and they still have to be applied).
>
> I also spoke to Alex about switching the licensing for dnsjnio to a BSD
> or ASLv2 license, and he started evaluating this issue with his company.
>
> As no one here seems to be a DNS expert imho we HAVE TO use dnsjava
> basic objects as a start because we don't know all the
> specifics/workarounds that could have been applied to such a widely
> adopted codebase and I'm pretty convinced that it would take a much
> bigger effort to rewrite also the message objects and codecs from scratch.
>
> Also, an asynchronous dns library IMHO does not belong to the directory
> project and should not have dependencies on anything in directory.
>
> The DNS library should be a very small library depending only on MINA.
>
> Stefano

I fully agree with you. So I'm really looking forward to get things 
done. After we have done all the "core" stuff we can switch the Message 
objects if we want.

So let's get started and get a lab ;-)

bye
Norman

Re: DNS Protocol (Was: DHCP Protocol Home)

[Stefano Bagnara <ap...@bago.org>]

Trustin Lee ha scritto:
> Unfortunately, I am not a DNS expert either.  We will give you as much
> support as we can if you have any questions about MINA.  But it's not
> free; you need to give us a rant whenever you find MINA sucks! ;)
> 
> It seems like we have three libraries on our table; dnsjava, dnsjnio,
> and ADS DNS protocol provider.  The authors of all three libraries
> could start to talk about getting the force together to form more
> sustainable community.
> 
> I'll CC the authors of dnsjava and dnsjnio in case they are interested.

I had conversations with both authors in past.

Alex (author of dnsjnio) already contacted Brian (author of dnsjava)
about extending dnsjava for asynchronous operations but Brian lately is
much less active on dnsjava and only applies few bug fixes every few
months (well, in fact I have also reported 2 really small, but critical
to me, bugs a while ago and they still have to be applied).

I also spoke to Alex about switching the licensing for dnsjnio to a BSD
or ASLv2 license, and he started evaluating this issue with his company.

As no one here seems to be a DNS expert imho we HAVE TO use dnsjava
basic objects as a start because we don't know all the
specifics/workarounds that could have been applied to such a widely
adopted codebase and I'm pretty convinced that it would take a much
bigger effort to rewrite also the message objects and codecs from scratch.

Also, an asynchronous dns library IMHO does not belong to the directory
project and should not have dependencies on anything in directory.

The DNS library should be a very small library depending only on MINA.

Stefano

Re: DNS Protocol (Was: DHCP Protocol Home)

[al...@nominet.org.uk]

Hi - 

I'm sorry for the delay in replying - I've just returned from holiday.

"Trustin Lee" <tr...@gmail.com> wrote on 12/06/2007 16:02:06:

> > As we currently depend on a "not-so-frequently-updated" (dnsjava)
> > library (and we are waiting for bugs to be fixed) and on
> > "not-so-widely-adopted" MPL licensed library (dnsjnio) I many times
> > considered starting a MINA-DNS library based on core dnsjava tokens.
> 
> It seems like we have three libraries on our table; dnsjava, dnsjnio,
> and ADS DNS protocol provider.  The authors of all three libraries
> could start to talk about getting the force together to form more
> sustainable community.
> 
> I'll CC the authors of dnsjava and dnsjnio in case they are interested.

What if there were a "frequently updated" dnsjava, containing all of the 
useful community-contributed patches (including dnsjnio), released under a 
BSD license - would that be a good solution?

Thanks,


Alex.