You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Alex Karasulu <ak...@apache.org> on 2007/06/11 17:17:58 UTC
DHCP Protocol Home (was: Re: [Vote] Sandboxing DHCP protocol)
Hey T,
The question is not where DHCP will go. It's definitely slated for
inclusion in ApacheDS to fullfil the Realm Controller concepts.
So, this is not a matter of whether or not it deserves to be here at
Directory. I don't want to turn this into that kind of discussion.
This is just a matter of maturity and documentation I think.
IMO MINA should not be the place to host all protocols. It can for
some time host protocols specific projects that do not have critical
community mass (like Asynchweb) until they blossom. But to try to
build MINA out to be a massive TLP in this way is a big mistake and
will result in the same issues that have confronted Jakarta. Keeping
the TLP lean and mean will keep it functional. I'd love tho to see
protocol analyzers and other protocol development tooling sub-projects
start at MINA tho.
Alex
On 6/11/07, Trustin Lee <tr...@gmail.com> wrote:
>
> On 6/10/07, Stefan Seelmann <se...@apache.org> wrote:
> > > [X] +1 : Let's sandbox it
>
> MINA project team might be interested in maintaining the codec /
> message class part of the sand-boxed protocol providers in the future.
> We are still busy improving MINA itself, so it will not happen right
> now, but I believe we will implement many standard protocols on top of
> MINA and provide them as MINA protocol codecs.
>
> Trustin
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
> --
> PGP Key ID: 0x0255ECA6
>
Re: DNS Protocol (Was: DHCP Protocol Home)
Posted by Michael Mealling <mi...@refactored-networks.com>.
Stefano Bagnara wrote:
> Michael Mealling ha scritto:
>> Having just done the same thing myself, a generalized version/framework
>> would be nice. I have the code for listening to both the UDP and TCP
>> sides. I also used dnsjava for the line level and message encoding stuff
>> with dnsjnio's async lookup. Sounds like we're all fairly close to each
>> other.
>
> Hi Michael,
>
> your name sounded familiar, so I checked with google and I found that
> you are the author of the NAPTR stuff, right?
Yep... That's me! Two communities are using NAPTR these days: the VOIP
community is using it in ENUM for routing VOIP calls and several
communities are using NAPTR records for looking up URNs (the largest is
EPCglobal and RFID tags).
> It is good to know that you are here and I hope we'll successfully
> collaborate toward a common goal.
Thanks! I'm not sure how active I'll be since once I'm done with this
project I'm off to something else. But I do know that my client desires
to Open Source this stuff. More on that later...
> As a starting point I would also like to involve dnsjava and dnsjnio
> author in the task (as active contributors or at least as reviewers),
> then we should put on the table what we already have and what we are
> willing to contribute.
If we end up not being able to get dnsjava in, I can at least help with
getting all of the DNS record types into whatever we end up with. By
necessity I've gotten good at parsing DNS packets. ;-)
DNSSEC is another thing altogether...
-MM
--
Michael Mealling Refactored Networks, LLC
CEO & President 1645 Old Hwy 41
Office: +1-678-581-9656 Suite 112, Box 138
Cell: +1-678-640-6884 Kennesaw, GA 30152
http://refactored-networks.com/
Re: DNS Protocol (Was: DHCP Protocol Home)
Posted by Stefano Bagnara <ap...@bago.org>.
Michael Mealling ha scritto:
> Having just done the same thing myself, a generalized version/framework
> would be nice. I have the code for listening to both the UDP and TCP
> sides. I also used dnsjava for the line level and message encoding stuff
> with dnsjnio's async lookup. Sounds like we're all fairly close to each
> other.
>
> -MM
Hi Michael,
your name sounded familiar, so I checked with google and I found that
you are the author of the NAPTR stuff, right?
It is good to know that you are here and I hope we'll successfully
collaborate toward a common goal.
As soon as the MINA guys will have decided whether we should start here
or in the lab we'll try to coordinate the efforts!
As a starting point I would also like to involve dnsjava and dnsjnio
author in the task (as active contributors or at least as reviewers),
then we should put on the table what we already have and what we are
willing to contribute.
Stefano
Re: DNS Protocol (Was: DHCP Protocol Home)
Posted by Michael Mealling <mi...@neonym.net>.
Having just done the same thing myself, a generalized version/framework
would be nice. I have the code for listening to both the UDP and TCP
sides. I also used dnsjava for the line level and message encoding stuff
with dnsjnio's async lookup. Sounds like we're all fairly close to each
other.
-MM
Stefano Bagnara 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?
>
> Stefano
>
Re: DNS Protocol (Was: DHCP Protocol Home)
Posted by 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)
Posted by 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)
Posted by 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)
Posted by 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)
Posted by 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)
Posted by 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)
Posted by 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)
Posted by 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)
Posted by 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)
Posted by 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)
Posted by 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)
Posted by 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)
Posted by 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)
Posted by 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)
Posted by 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)
Posted by 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)
Posted by 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)
Posted by 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)
Posted by 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)
Posted by 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)
Posted by 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)
Posted by 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)
Posted by 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)
Posted by 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)
Posted by 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)
Posted by 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)
Posted by 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)
Posted by 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)
Posted by 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)
Posted by 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)
Posted by 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)
Posted by 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)
Posted by 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)
Posted by 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)
Posted by 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)
Posted by 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)
Posted by 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)
Posted by 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)
Posted by 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)
Posted by Enrique Rodriguez <en...@gmail.com>.
On 6/12/07, Stefano Bagnara <ap...@bago.org> wrote:
> ...
> 1) clients trying to identify a target for the connection (most
> protocols will only need the "IN A" lookup to resolve an host, smtp for
> example needs first an IN MX and then IN A lookup).
>
> 2) servers trying to check reverse resolvability of connecting hosts (IN
> PTR lookups)
>
> 3) a recursive dns server implementation trying to resolve some dns
> request on third party dns host.
Stefano's asynchronous use cases are a good scope of work for this
library. We (Directory) could be the "recursive dns server
implementation" and could use this library as an asynch client for
upstream queries and for codecs and messages.
Enrique
Re: DNS Protocol (Was: DHCP Protocol Home)
Posted by Stefano Bagnara <ap...@bago.org>.
Julien Vermillard ha scritto:
> Hi,
> I'm interested in a lightweight DNS server, I don't know much the DNS
> byte level protocol, but I can help for the MINA part :)
Hi Julien,
my first doubt is how to approach the dns resolution in MINA.
DNS is a bit different from other protocols because most times it is not
used directly as a communication protocol, but only as an helper to
other protocols.
I would start from use cases and here is a list of use cases for the dns
library I can think now:
1) clients trying to identify a target for the connection (most
protocols will only need the "IN A" lookup to resolve an host, smtp for
example needs first an IN MX and then IN A lookup).
2) servers trying to check reverse resolvability of connecting hosts (IN
PTR lookups)
3) a recursive dns server implementation trying to resolve some dns
request on third party dns host.
In every case we already have an ongoing connection (often mina based)
on a different protocol that will require the asynchronous dns lookup.
The dns resolution could happen on these transport layers:
1) a single tcp connection to the preferred server (or round robin on
multiple servers) for each lookup
2) a shared tcp connection to the preferred server
3) a shared udp channel to the preferred server
dnsjava already has a Message object used both for queries and for
responses.
A lookup in dns at an high level have this layers:
LOOKUP: a lookup object managing caches for success and failures,
recursion for CNAMEs, search paths, temporary/permanent error
management: users of a dns library will often make a single call to this
service and work with the result (even if it is a temporary error). This
service requires a RESOLVER that will handle the real queries.
RESOLVER: a resolver is the real client of the dns protocol. The
arguments are the hostname (the dnsserver) and the transport to be used
(UDP/TCP). You send a Message and you receive back either a response
Message or an IOException (mostly a TimeoutException).
EXTENDEDRESOLVER: this is a better resolver handling multiple hosts. It
may use different strategies to use multiple servers and multiple
resolvers to handle the queries. It may use round robin, it may use the
server in a sequence or run the same query concurrently against multiple
servers and take the fastest answer. This service depends on 1..N
asynchronous resolvers.
Currently in dnsjnio+dnsjava solution every of this layers has its own
processing thread. One thread for each resolver, ohe thread for the
extended resolver to manage the queues for resolvers, One thread for the
lookup "executor". Moving to MINA I would like to also reduce the
minimum threads, if possible.
I think that for the Message part we can use dnsjava code directly (but
here we'll have to deal with dnsjava bugs, so maybe it is better to
clone the whole Message structure into a new package).
For the "LOOKUP" service I already have ported the synchronous dnsjava
lookup helper to an asynchronous service and it is mostly based on
dnsjava BSD code and custom work from me. For the Resolvers instead I
currently use the dnsjnio stuff that is MPL, so we should better write
our own mina handler/filters/codecs from scratch.
It seems the most basic part to start with is the simple resolver
working on UDP.
The simple resolver has a simple interface because you send messages and
receive messages over a single connection. How to build the extended
resolver on top of this? the extended resolver does not have a
"connection" but instead rely on a collection of resolvers. Otherwise it
expose the same service of the simple resolver. What is the best way to
manage this with MINA?
Should we start sandboxing some code? What is more appropriate? (JIRA
attachment / a sandbox inside james or mina repositories / an apache lab
project)
Stefano
Re: DNS Protocol (Was: DHCP Protocol Home)
Posted by Julien Vermillard <jv...@archean.fr>.
Le mardi 12 juin 2007 à 19:08 -0700, Enrique Rodriguez a écrit :
> On 6/12/07, Richard Wallace <rw...@thewallacepack.net> wrote:
> > Stefano Bagnara wrote:
> > > ...
> > > Furthermore the current dns project has dependencies on shared-protocol
> > > and other directory specific modules I don't even care of
> > > understanding/compiling.
> > >
> > This is one complaint I had as well. I would definitely like to see a
> > TLP called Apache DNS that produces a client and server. One option for
> > the server could be to plugin to the Apache Directory for doing
> > resolutions, but there definitely needs to be a greater level of
> > abstraction than there is now.
>
> The protocol-dns store should be pretty separable today. We
> identified an issue with transitive deps, but we addressed it within
> the last 3 weeks. There should only be trivial deps on other
> Directory artifacts, if any. Most of the deps come from simply using
> Directory parent POMs, which makes sense for us, of course, since we
> know our impl will be using our Directory back-end.
>
> In any case, with a move to MINA and breaking from the Directory
> parent POM, it should be easy to make this lightweight. Because the
> Directory deps are behind the store interface (RecordStore), the
It's true, but there is a dependency for some ADS code in 1 place. I
need to remember and I send you the patch :)
Anyway I compiled ADS DNS server without any other ADS code, with only 1
or 2 lines of patching.
> server-side handler could go to MINA for those that want a lighter
> server. Though, it's not much code and, therefore, it might not be
> worth attempting to make a one-size-fits-all server handler.
>
> In any case, the focus should be on the asynch client since that is
> the most pressing need.
>
> Enrique
Julirn
Re: DNS Protocol (Was: DHCP Protocol Home)
Posted by Trustin Lee <tr...@gmail.com>.
On 6/13/07, Stefano Bagnara <ap...@bago.org> wrote:
> Enrique Rodriguez ha scritto:
> > In any case, the focus should be on the asynch client since that is
> > the most pressing need.
>
> Here is a list of goals:
>
> 1) MINA based dns protocol/codec/message objects
>
> 2) MINA based client, supporting multiple server, timeouts, recursions,
> supporting TCP and UDP, reusing a single (or a pool) of connections/ports.
>
> 3) Pluggable Cache, DNSSEC, TSIG support.
>
> 4) a very small authoritative only, non recursive DNS server to run
> integration tests for DNS based products.
>
> As far as I understand the Directory project is also interested in
> creating a full recursive dnsserver.
> This will need a storage and a lot more of code and maybe this will
> belong to directory (as Emmanuel says).
> The directory project will probably use the dns client as is for the
> recursion and the dns protocol/codecs part to write the server part.
Thank you Stefano for summarizing the discussion. Let's start from
these four goals if there's no objection.
MINA PMC is discussing about hosting the project under MINA project or
Lab. Hopefully I will get back to you guys with the answer soon.
Stay tuned!
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
Re: DNS Protocol (Was: DHCP Protocol Home)
Posted by Stefano Bagnara <ap...@bago.org>.
Enrique Rodriguez ha scritto:
> In any case, the focus should be on the asynch client since that is
> the most pressing need.
Here is a list of goals:
1) MINA based dns protocol/codec/message objects
2) MINA based client, supporting multiple server, timeouts, recursions,
supporting TCP and UDP, reusing a single (or a pool) of connections/ports.
3) Pluggable Cache, DNSSEC, TSIG support.
4) a very small authoritative only, non recursive DNS server to run
integration tests for DNS based products.
As far as I understand the Directory project is also interested in
creating a full recursive dnsserver.
This will need a storage and a lot more of code and maybe this will
belong to directory (as Emmanuel says).
The directory project will probably use the dns client as is for the
recursion and the dns protocol/codecs part to write the server part.
Stefano
Re: DNS Protocol (Was: DHCP Protocol Home)
Posted by Enrique Rodriguez <en...@gmail.com>.
On 6/12/07, Richard Wallace <rw...@thewallacepack.net> wrote:
> Stefano Bagnara wrote:
> > ...
> > Furthermore the current dns project has dependencies on shared-protocol
> > and other directory specific modules I don't even care of
> > understanding/compiling.
> >
> This is one complaint I had as well. I would definitely like to see a
> TLP called Apache DNS that produces a client and server. One option for
> the server could be to plugin to the Apache Directory for doing
> resolutions, but there definitely needs to be a greater level of
> abstraction than there is now.
The protocol-dns store should be pretty separable today. We
identified an issue with transitive deps, but we addressed it within
the last 3 weeks. There should only be trivial deps on other
Directory artifacts, if any. Most of the deps come from simply using
Directory parent POMs, which makes sense for us, of course, since we
know our impl will be using our Directory back-end.
In any case, with a move to MINA and breaking from the Directory
parent POM, it should be easy to make this lightweight. Because the
Directory deps are behind the store interface (RecordStore), the
server-side handler could go to MINA for those that want a lighter
server. Though, it's not much code and, therefore, it might not be
worth attempting to make a one-size-fits-all server handler.
In any case, the focus should be on the asynch client since that is
the most pressing need.
Enrique
Re: DNS Protocol (Was: DHCP Protocol Home)
Posted by Enrique Rodriguez <en...@gmail.com>.
On 6/12/07, Trustin Lee <tr...@gmail.com> wrote:
> On 6/13/07, Richard Wallace <rw...@thewallacepack.net> wrote:
> ...
> > Next, is how we'll get the project started.
> > 1) Start from scratch
> > 2) Copy protocol-dns and build from there, using dnsjava and dnsjnio for
> > reference.
> > 3) Pursue importing, relicensing under ASL 2.0, and refactoring dnsjava
> > (http://www.dnsjava.org/index.html), with permission from Brian
> > Wellington, the author.
> > 4) Import dnsjava under the BSD license, changing the name and package
> > and making a reference to the original dnsjava in the LICENSE file
> > (assuming this is the way it works according to the BSD license).
> > 5) Pursue importing, relicensing under ASL 2.0, and building from
> > dnsjnio (http://sourceforge.net/projects/dnsjnio/), with permission from
> > the author, Alex.
> >
> > I like #3 if Brian is willing to contribute the code. It is mature and
> > well used by other projects. It has a good, solid suite of unit tests
> > that will help in porting it to use MINA. I don't like the idea of
> > trying to use dnsjava without Brian's approval even if it is within the
> > bounds of the BSD license. So if we can't get approval from him, my
> > next choice would be #2. I haven't had a chance to look much at
> > dnsjnio, so I'm not sure about #5, although Stefano seems to think that
> > he'd be more willing to relicense his code.
> >
> > I'm sure there are some alternatives I'm missing. But I hope this is a
> > good start at summarizing the options we've come up with so far.
>
> I prefer the option #3, too. WDYT guys?
My thoughts are same as Richard. #3, then #2, no experience with #5.
Enrique
Re: DNS Protocol (Was: DHCP Protocol Home)
Posted by Norman <no...@apache.org>.
Trustin Lee schrieb:
> On 6/13/07, Richard Wallace <rw...@thewallacepack.net> wrote:
>> So let's try and enumerate our options and figure out which ones we like
>> the most and want to pursue first.
>>
>> First, there's there "where" of hosting:
>> 1) Apache Labs
>> 2) Apache Incubating
>> 3) MINA subproject
>>
>> It sounds like the consensus so far is to host it as a MINA subproject.
>> Should we take a vote on that?
>
> MINA PMC is discussing on this issue right now. I'll announce the
> result in 3 days.
>
>> Next, is how we'll get the project started.
>> 1) Start from scratch
>> 2) Copy protocol-dns and build from there, using dnsjava and dnsjnio for
>> reference.
>> 3) Pursue importing, relicensing under ASL 2.0, and refactoring dnsjava
>> (http://www.dnsjava.org/index.html), with permission from Brian
>> Wellington, the author.
>> 4) Import dnsjava under the BSD license, changing the name and package
>> and making a reference to the original dnsjava in the LICENSE file
>> (assuming this is the way it works according to the BSD license).
>> 5) Pursue importing, relicensing under ASL 2.0, and building from
>> dnsjnio (http://sourceforge.net/projects/dnsjnio/), with permission from
>> the author, Alex.
>>
>> I like #3 if Brian is willing to contribute the code. It is mature and
>> well used by other projects. It has a good, solid suite of unit tests
>> that will help in porting it to use MINA. I don't like the idea of
>> trying to use dnsjava without Brian's approval even if it is within the
>> bounds of the BSD license. So if we can't get approval from him, my
>> next choice would be #2. I haven't had a chance to look much at
>> dnsjnio, so I'm not sure about #5, although Stefano seems to think that
>> he'd be more willing to relicense his code.
>>
>> I'm sure there are some alternatives I'm missing. But I hope this is a
>> good start at summarizing the options we've come up with so far.
>
> I prefer the option #3, too. WDYT guys?
>
> Trustin
I have spoken to Brian to in the past about bugs etc. and I whould agree
with Stefano that I don't think he will contribute his code. But if you
want give it a try.
bye
Norman
Re: DNS Protocol (Was: DHCP Protocol Home)
Posted by Trustin Lee <tr...@gmail.com>.
On 6/13/07, Richard Wallace <rw...@thewallacepack.net> wrote:
> So let's try and enumerate our options and figure out which ones we like
> the most and want to pursue first.
>
> First, there's there "where" of hosting:
> 1) Apache Labs
> 2) Apache Incubating
> 3) MINA subproject
>
> It sounds like the consensus so far is to host it as a MINA subproject.
> Should we take a vote on that?
MINA PMC is discussing on this issue right now. I'll announce the
result in 3 days.
> Next, is how we'll get the project started.
> 1) Start from scratch
> 2) Copy protocol-dns and build from there, using dnsjava and dnsjnio for
> reference.
> 3) Pursue importing, relicensing under ASL 2.0, and refactoring dnsjava
> (http://www.dnsjava.org/index.html), with permission from Brian
> Wellington, the author.
> 4) Import dnsjava under the BSD license, changing the name and package
> and making a reference to the original dnsjava in the LICENSE file
> (assuming this is the way it works according to the BSD license).
> 5) Pursue importing, relicensing under ASL 2.0, and building from
> dnsjnio (http://sourceforge.net/projects/dnsjnio/), with permission from
> the author, Alex.
>
> I like #3 if Brian is willing to contribute the code. It is mature and
> well used by other projects. It has a good, solid suite of unit tests
> that will help in porting it to use MINA. I don't like the idea of
> trying to use dnsjava without Brian's approval even if it is within the
> bounds of the BSD license. So if we can't get approval from him, my
> next choice would be #2. I haven't had a chance to look much at
> dnsjnio, so I'm not sure about #5, although Stefano seems to think that
> he'd be more willing to relicense his code.
>
> I'm sure there are some alternatives I'm missing. But I hope this is a
> good start at summarizing the options we've come up with so far.
I prefer the option #3, too. 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)
Posted by Stefano Bagnara <ap...@bago.org>.
Richard Wallace ha scritto:
> Next, is how we'll get the project started.
> 1) Start from scratch
I would avoid this, even if I think our final result will have very few
things in common with the original work.
> 2) Copy protocol-dns and build from there, using dnsjava and dnsjnio for
> reference.
> 3) Pursue importing, relicensing under ASL 2.0, and refactoring dnsjava
> (http://www.dnsjava.org/index.html), with permission from Brian
> Wellington, the author.
> 4) Import dnsjava under the BSD license, changing the name and package
> and making a reference to the original dnsjava in the LICENSE file
> (assuming this is the way it works according to the BSD license).
As I wrote previously unless someone will state that he/she is willing
to implement DNSSEC, Cache and other more complex issues related to dns,
I really think we should go for starting from dnsjava code: we will
probably need big refactorings from this and probably we'll end
rewriting 90% of it, but I think that the overall quality will be much
better it we refactor than if we write from scratch.
Let's remember that DNSSEC and Cache management (using TTL expiration)
is a big part of the dnsjava library, and to add asynchronous suopport
there is no need to rewrite it from scratch (if we try to mantain its
Message model). Furthermore if we try to have similar message models it
will be more easy to port applications based on dnsjava (e.g: JAMES jSPF
and JAMES Server are dnsjava apps)
> 5) Pursue importing, relicensing under ASL 2.0, and building from
> dnsjnio (http://sourceforge.net/projects/dnsjnio/), with permission from
> the author, Alex.
Please note that dnsjnio is only a simple wrapper around dnsjava adding
asynchronouos capability using NIO directly. If we start a sandbox in
MINA it seems clear that the library will have to use MINA, so most code
is not reusable.
Of course I would really like to see Alex as a contributor to this
project too!
I think dnsjava is great but it's bigger limit is Brian Wellington is a
single mantainer (even if he has been really good in this years).
> I like #3 if Brian is willing to contribute the code. It is mature and
> well used by other projects. It has a good, solid suite of unit tests
> that will help in porting it to use MINA. I don't like the idea of
> trying to use dnsjava without Brian's approval even if it is within the
> bounds of the BSD license. So if we can't get approval from him, my
> next choice would be #2. I haven't had a chance to look much at
> dnsjnio, so I'm not sure about #5, although Stefano seems to think that
> he'd be more willing to relicense his code.
See the previous paragraph.
> I'm sure there are some alternatives I'm missing. But I hope this is a
> good start at summarizing the options we've come up with so far.
I see the same alternatives.
Stefano
Re: DNS Protocol (Was: DHCP Protocol Home)
Posted by Richard Wallace <rw...@thewallacepack.net>.
So let's try and enumerate our options and figure out which ones we like
the most and want to pursue first.
First, there's there "where" of hosting:
1) Apache Labs
2) Apache Incubating
3) MINA subproject
It sounds like the consensus so far is to host it as a MINA subproject.
Should we take a vote on that?
Next, is how we'll get the project started.
1) Start from scratch
2) Copy protocol-dns and build from there, using dnsjava and dnsjnio for
reference.
3) Pursue importing, relicensing under ASL 2.0, and refactoring dnsjava
(http://www.dnsjava.org/index.html), with permission from Brian
Wellington, the author.
4) Import dnsjava under the BSD license, changing the name and package
and making a reference to the original dnsjava in the LICENSE file
(assuming this is the way it works according to the BSD license).
5) Pursue importing, relicensing under ASL 2.0, and building from
dnsjnio (http://sourceforge.net/projects/dnsjnio/), with permission from
the author, Alex.
I like #3 if Brian is willing to contribute the code. It is mature and
well used by other projects. It has a good, solid suite of unit tests
that will help in porting it to use MINA. I don't like the idea of
trying to use dnsjava without Brian's approval even if it is within the
bounds of the BSD license. So if we can't get approval from him, my
next choice would be #2. I haven't had a chance to look much at
dnsjnio, so I'm not sure about #5, although Stefano seems to think that
he'd be more willing to relicense his code.
I'm sure there are some alternatives I'm missing. But I hope this is a
good start at summarizing the options we've come up with so far.
Rich
Enrique Rodriguez wrote:
> On 6/12/07, Trustin Lee <tr...@gmail.com> wrote:
>> ...
>> Oops, I saw this message after I pressed the send button. Is there
>> any reason you would avoid the incubation? If there's an explicit
>> reason that the incubator is not preferred, we could start the project
>> at the Lab and decide under which project it should be later.
>
> I am in favor of a MINA sandbox. I think some projects will have
> issues relying on incubating code. Certainly if protocol-dns code
> moves to MINA and we bring in dnsjava somehow we could have a nice
> library faster than Incubation would take. I'd like to be able to use
> it on Directory.
>
> Enrique
Re: DNS Protocol (Was: DHCP Protocol Home)
Posted by Enrique Rodriguez <en...@gmail.com>.
On 6/12/07, Trustin Lee <tr...@gmail.com> wrote:
> ...
> Oops, I saw this message after I pressed the send button. Is there
> any reason you would avoid the incubation? If there's an explicit
> reason that the incubator is not preferred, we could start the project
> at the Lab and decide under which project it should be later.
I am in favor of a MINA sandbox. I think some projects will have
issues relying on incubating code. Certainly if protocol-dns code
moves to MINA and we bring in dnsjava somehow we could have a nice
library faster than Incubation would take. I'd like to be able to use
it on Directory.
Enrique
Re: DNS Protocol (Was: DHCP Protocol Home)
Posted by Enrique Rodriguez <en...@gmail.com>.
On 6/12/07, Alex Karasulu <ak...@apache.org> wrote:
> Sounds like the community has spoken and this is a great thing even though I
> personally perferred to develop it at Directory. Yet I understand that
> others
> want to have this distinct and it should be. I'm sure we can leverage
> whatever
> DNS libraries are produced by this project to have an LDAP backed store
> integrated into ApacheDS. Futhermore those involved at Directory can
> participate
> in the effort if they would like to so it's a win win situation.
> ...
Count me in and it sounds from Alex' comments that we would likely
have support from the Directory PMC to contribute code. A solid DNS
provider with upstream support is part of our "realm control" goals
and it has been slow going. A revitalized effort around messages,
codecs, and asynch client-side would really help Directory get to a
DNS provider faster, with more supported record types, upstream
support, and zone transfer.
Enrique
Re: DNS Protocol (Was: DHCP Protocol Home)
Posted by Alex Karasulu <ak...@apache.org>.
Sounds like the community has spoken and this is a great thing even though I
personally perferred to develop it at Directory. Yet I understand that
others
want to have this distinct and it should be. I'm sure we can leverage
whatever
DNS libraries are produced by this project to have an LDAP backed store
integrated into ApacheDS. Futhermore those involved at Directory can
participate
in the effort if they would like to so it's a win win situation.
More inline ...
On 6/13/07, Trustin Lee <tr...@gmail.com> wrote:
>
> On 6/13/07, Stefano Bagnara <ap...@bago.org> wrote:
> > I think that MINA PMC should decide whether a DNS library should be part
> > of the mina TLP or not and if they (you) share my opinion that MINA
> > really need an asynchronous dns libraries and it is the right home for
> > this task then we should start working here, otherwise we could try with
> > the lab, or we could work outside from the ASF and try to incubate later
> > (but I would avoid this if possible).
>
> Oops, I saw this message after I pressed the send button. Is there
> any reason you would avoid the incubation? If there's an explicit
> reason that the incubator is not preferred, we could start the project
> at the Lab and decide under which project it should be later.
Well after this discussion I think it might be best under the MINA TLP for
now
as a sandboxed project until the PMC determines it's ready to be promoted
into a sub project.
My reasons for recommending this is that most of the people involved in the
push are MINA committers if not ASF committers. There is a lower barrier
to gain committership anyway for existing ASF committers. The lab is fine
as well but I think we can move faster this way with the community.
Also those that are not ASF committers can easily be integrated into the
community
with their contributions.
WDYT?
Alex
Re: DNS Protocol (Was: DHCP Protocol Home)
Posted by Trustin Lee <tr...@gmail.com>.
On 6/13/07, Stefano Bagnara <ap...@bago.org> wrote:
> I think that MINA PMC should decide whether a DNS library should be part
> of the mina TLP or not and if they (you) share my opinion that MINA
> really need an asynchronous dns libraries and it is the right home for
> this task then we should start working here, otherwise we could try with
> the lab, or we could work outside from the ASF and try to incubate later
> (but I would avoid this if possible).
Oops, I saw this message after I pressed the send button. Is there
any reason you would avoid the incubation? If there's an explicit
reason that the incubator is not preferred, we could start the project
at the Lab and decide under which project it should be later.
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
Re: DNS Protocol (Was: DHCP Protocol Home)
Posted by Stefano Bagnara <ap...@bago.org>.
Enrique Rodriguez ha scritto:
> On 6/12/07, Stefano Bagnara <ap...@bago.org> wrote:
>> ...
>> Anyway I think Enrique comments could help: is Enrique subscribed to
>> MINA list or should we CC again to directory?
>
> I'm on MINA (and Directory) but currently busy with work. I'm almost
> caught up on this thread and will likely respond in ~6 hrs.
>
> Enrique
I was just checking committers and PMC members for MINA and I saw you
are listed as PMC member on mina, so you are the man we need ;-)
I think that MINA PMC should decide whether a DNS library should be part
of the mina TLP or not and if they (you) share my opinion that MINA
really need an asynchronous dns libraries and it is the right home for
this task then we should start working here, otherwise we could try with
the lab, or we could work outside from the ASF and try to incubate later
(but I would avoid this if possible).
Stefano
Re: DNS Protocol (Was: DHCP Protocol Home)
Posted by Enrique Rodriguez <en...@gmail.com>.
On 6/12/07, Stefano Bagnara <ap...@bago.org> wrote:
> ...
> Anyway I think Enrique comments could help: is Enrique subscribed to
> MINA list or should we CC again to directory?
I'm on MINA (and Directory) but currently busy with work. I'm almost
caught up on this thread and will likely respond in ~6 hrs.
Enrique
Re: DNS Protocol (Was: DHCP Protocol Home)
Posted by Stefano Bagnara <ap...@bago.org>.
Enrique Rodriguez ha scritto:
> Message objects and codecs are generally trivial though they do
> represent some work. I could help out with refactoring any messages
> and codecs to new conventions and it sounds like Rich is, too. It
> could go pretty quickly and it sounds like there are unit tests
> available.
>
> Also, we could start with dnsjava and slowly migrate to whatever our
> thinking is about these objects, to prevent getting bogged down in a
> bigger project.
+1
> The hard part is in the protocol workflow, be it on the client side or
> the server side. Michael mentioned some use-cases for the server-side
> and we'll have to keep that in mind but there are techniques for
> making things flexible and extensible. A lot of what has been lacking
> on Directory in this regard is feedback from users who drive us to add
> extension points, remove deps, etc. In which case, it sounds like
> getting this going at MINA and with a focus on a client will benefit
> everyone.
>
> Regarding client-side workflow, the use cases for Kerberos (my focus)
> are similar to DNS in that it is a means to an end. You acquire
> Kerberos credentials before accessing a subsequent service. I am
> interested in what patterns emerge for handling multiple, disparate
> protocol calls since I am in the middle of multi-protocol client work
> on Directory these days. I haven't hit it yet, but now that I think
> about it, I'll have the same problems in DNS that everyone on this
> thread is having.
Cool! I hope we can find a pattern that fits MINA so that it will be
easy to integrate multiple protocols using MINA.
Stefano
Re: DNS Protocol (Was: DHCP Protocol Home)
Posted by Enrique Rodriguez <en...@gmail.com>.
On 6/12/07, Stefano Bagnara <ap...@bago.org> wrote:
> Richard Wallace ha scritto:
> > Stefano Bagnara wrote:
> >>>> IMHO it is much better to start using the dnsjava objects for
> >>>> encoding/decoding as a start also because it is much more stable than
> >>>> the directory code.
> >>>>
> >>>> Stefano
> >>>>
> >>> I wouldn't mind lifting ideas and workarounds from the dnsjava code, but
> >>> I don't think we need to go so far as to take all their base classes.
> >>> One problem that I remember seeing with how they do their
> >>> decoding/encoding is that it is actually a part of the message object,
> >>> which does not seem like a good idea to me. One thing that appealed to
> >>> me about the way Enrique did the base objects in protocol-dns is that
> >>> the Message object and various record types are actually Value
> >>> Objects. This makes a lot of sense. Once constructed they should
> >>> never change.
> >>>
> >> I think this also applies to dnsjava objects: they ARE value object.
> >> IMHO we can refactor them, we could also extract parsing into codec
> >> classes but I still think that refactoring from dnsjava is much better
> >> than starting from scratch.
> >>
> > Some of the dnsjava objects are Value Objects and some aren't. For
> > instance, a Message object can be modified anytime during it's lifetime,
> > but it looks like Records are Value Objects. But that's a minor detail
> > that could be worked out. And refactoring is fun, so count me in if we
> > can get consent.
>
> I agree: refactoring is the best part if you have unit tests to prove
> you did everything right ;-)
Message objects and codecs are generally trivial though they do
represent some work. I could help out with refactoring any messages
and codecs to new conventions and it sounds like Rich is, too. It
could go pretty quickly and it sounds like there are unit tests
available.
Also, we could start with dnsjava and slowly migrate to whatever our
thinking is about these objects, to prevent getting bogged down in a
bigger project.
The hard part is in the protocol workflow, be it on the client side or
the server side. Michael mentioned some use-cases for the server-side
and we'll have to keep that in mind but there are techniques for
making things flexible and extensible. A lot of what has been lacking
on Directory in this regard is feedback from users who drive us to add
extension points, remove deps, etc. In which case, it sounds like
getting this going at MINA and with a focus on a client will benefit
everyone.
Regarding client-side workflow, the use cases for Kerberos (my focus)
are similar to DNS in that it is a means to an end. You acquire
Kerberos credentials before accessing a subsequent service. I am
interested in what patterns emerge for handling multiple, disparate
protocol calls since I am in the middle of multi-protocol client work
on Directory these days. I haven't hit it yet, but now that I think
about it, I'll have the same problems in DNS that everyone on this
thread is having.
Enrique
Re: DNS Protocol (Was: DHCP Protocol Home)
Posted by Enrique Rodriguez <en...@gmail.com>.
On 6/12/07, Stefano Bagnara <ap...@bago.org> wrote:
> Richard Wallace ha scritto:
> ...
> > I don't know what the details should be. As of this point I'm not an
> > ASF committer so maybe I should just work on it until I get something
> > going and then put it up somewhere I've got access and we can move it
> > into Apache at some point in the future.
>
> You should start sending the CCLA/ICLA via FAX to the ASF, so that it
> will be more easy later to get you on a repository :-)
I agree that it is better to get a repo in place and contribute there.
Working solo is a slippery slope. Over the years at ASF I've heard
from people working solo who intended to contribute back but it rarely
happens. Now, in just the last 6 months, I had to fork a project to
hit some work goals and I'm wondering if I'll ever get a chance to
contribute back my code (which I still intend to do). Though, in that
case, the code I forked needed a serious overhaul.
Enrique
Re: DNS Protocol (Was: DHCP Protocol Home)
Posted by Stefano Bagnara <ap...@bago.org>.
Trustin Lee ha scritto:
> What do you think about the Incubator? I believe there are enough
> supporters in the ASF, so writing a proposal for the incubation might
> attract more people here. I'd love to become a mentor if I deserves a
> mentor.
>
> Trustin
I excluded Incubator only because I thought (and most projects are) that
it was for already existing projects being donated to the ASF. Most
procedures in the Incubator are related to the licenses/grants of
contributed code and to make sure there is a community interested in the
contributed code. In this case we are trying to build something new, so
there is less legal/community problems: if we don't have enough
community we won't be able to create something working, so the sandbox
will die with no side effects.
It seems to me that Incubator is a bit "oversized" for the dns effort:
but I think that this choice is a MINA PMC choice, and I read you
already discussing this, so I will just wait :-)
Thank you,
Stefano
Re: DNS Protocol (Was: DHCP Protocol Home)
Posted by Trustin Lee <tr...@gmail.com>.
Hi folks,
On 6/13/07, Stefano Bagnara <ap...@bago.org> wrote:
<snip>Great discussion</snip>
> At the moment here is the people that show interest contributing to this
> dns library project:
> Julien Vermillard: directory and mina projects
> Richard Wallace: not an ASF committer
> Stefano Bagnara: james project
> Norman Maurer: james project
>
> As Apache JAMES PMC member I can only tell that probably JAMES is not
> the place for this dns project as we would be users for this library but
> DNS is not so related to email that is JAMES primary topic.
>
> Now I think that the Mina PMC has to decide whether this work should be
> started in a MINA sandbox or we should better request a Lab for it.
>
> For my experience it is better to avoid working offline and instead
> start working directly in an ASF repository, so it is much more clear to
> everyone who committed each code and where every piece of code has been
> contributed from.
>
> The main problem is that Apache Labs does not allow to create new ASF
> committers, so to have you aboard our only chance is to find a space in
> another project (MINA?).
What do you think about the Incubator? I believe there are enough
supporters in the ASF, so writing a proposal for the incubation might
attract more people here. I'd love to become a mentor if I deserves a
mentor.
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
Re: DNS Protocol (Was: DHCP Protocol Home)
Posted by Enrique Rodriguez <en...@gmail.com>.
On 6/12/07, Stefano Bagnara <ap...@bago.org> wrote:
> ...
> Anyway I think Enrique comments could help: is Enrique subscribed to
> MINA list or should we CC again to directory?
I never wanted to implement a DNS library. But, like others here, I
had some issues with the existing DNS capabilities and I hit a wall
w.r.t. responsiveness.
My main interest is in completing some higher-lever integration use
cases for network infrastructure. I'm thinking of the interplay of
DHCP and DDNS, the ability to store Kerberos/LDAP service lookup info
in SRV records, and the ability to use Kerberos to protect DNS. Of
course, I'd like to make this easy for users with as much
automatically happening as possible. As Alex K mentioned we have
triggers and interceptors for this sort of thing in Directory. So,
putting it bluntly, the less reusable library work I have to do, the
better.
Regarding DNS itself, I am most interested in the security pieces and
can add the most value there, in particular DNSSEC and TSIG w/
Kerberos.
Enrique
Re: DNS Protocol (Was: DHCP Protocol Home)
Posted by Richard Wallace <rw...@thewallacepack.net>.
Stefano Bagnara wrote:
> Richard Wallace ha scritto:
>
>> Stefano Bagnara wrote:
>>
>>> In particular I don't have any DNS specific knowledge and I really would
>>> like to change as few as possible from a working and widely adopted
>>> implentation :-)
>>>
>>>
>>>
>> I agree we should reuse what we can. I saw you have talked with both
>> authors of dnsjava and dnsjnio, did you get the feeling from Brian that
>> he would be willing to contribute his code to the Apache project? I
>> know it's already BSD, but I'd feel alot better about reusing his code
>> if he were a willing contributor.
>>
>
> My feeling about Alex (dnsjnio) is that he is willing to license his
> code under more permissive license, but we never talked about
> contributing to ASF. Instead I never talked to Brian about contributing
> code to ASF.
>
> I think Brian is a lot conservative on dnsjava so I don't think he is
> willing to work on enhancement/fork of his library under the ASF umbrella.
>
> If you instead talk about trying to get a "software grant" from Brian to
> the ASF for the copyrights of dnsjava I don't have idea about what's
> Brian opinion (and if he is has exclusive copyrights on that code), so
> maybe you should anyway consider the BSD license terms as our way.
> IANAL and I don't often get most "subtle" license issues, but if I
> understood it we can take the BSD code, we should only take care of not
> using the DNSJAVA/XBILL names inside our code and maybe add a reference
> in NOTICE to tell that some of our code is based on DNSJAVA, right?
>
>
AFAIK, the NOTICE is all that is required. But like I said I'd feel
much better if we could get Brian's support. If not, I think I have to
go back to trying to build up protocol-dns and just looking to dnsjava
for ideas.
>>>>> If we reuse basic classes from dnsjava we can take the TSIG and other
>>>>> dns supporting tools as is from the dnsjava library.
>>>>>
>>>>>
>>>> I don't think we necessarily need to take the base classes from
>>>> dnsjava. There is already a good set of base classes in
>>>> protocol-dns. Looking at how other projects support the protocol and
>>>> what workarounds
>>>> they've had to implement is a good idea.
>>>>
>>>>
>>> Well, I was simply stating my goals. I won't be able to implement the
>>> full library starting from the protocol-dns sandbox.
>>> What I can try to do is to start from dnsjava and provide mina based
>>> transport and a mina based lookup class (that I already have based on
>>> dnsjnio).
>>>
>>>
>>>
>> The more I think of this the more I'm starting to like the idea of
>> refactoring dnsjava into something more MINA based. I wouldn't mind
>> taking a stab at that. I'm wondering what Enrique's take is on this,
>> since he's the original author of protocol-dns (and many of the other
>> protocol- implementations in Directory).
>>
>
> I think protocol-dns is much more lightweight than dnsjava, but it is
> also very limited to exporting directory data via the DNS protocol,
> without DNSSEC, without recursion and so on.
>
> Anyway I think Enrique comments could help: is Enrique subscribed to
> MINA list or should we CC again to directory?
>
>
>>>>> I just want to add asynchronous support. I already have it in
>>>>> dnsjnio+dnsjava but I don't like to depend on dnsjava and dnsjnio only
>>>>> because of their licensing (dnsjnio is MPL) and release workflow
>>>>> (dnsjava author is not so reactive applying even the smallest patch).
>>>>>
>>>>> Furthermore the current dns project has dependencies on shared-protocol
>>>>> and other directory specific modules I don't even care of
>>>>> understanding/compiling.
>>>>>
>>>>>
>>>> This is one complaint I had as well. I would definitely like to see a
>>>> TLP called Apache DNS that produces a client and server. One option for
>>>> the server could be to plugin to the Apache Directory for doing
>>>> resolutions, but there definitely needs to be a greater level of
>>>> abstraction than there is now.
>>>>
>>>>
>>> IMHO MINA is the best place for a dns library: the main cause is that
>>> most protocols require dns-lookups to work, so a MINA developer would
>>> probably use also dns resolution.
>>> I bet most people using MINA still rely on synchronous dnsjava or
>>> synchronous java.net lookups and asynschronous dns lookups should be
>>> part of the standard mina distribution.
>>>
>>>
>> I think that it makes sense to start it as a subproject of some existing
>> project until it gets a community of its own. And I think it does make
>> more sense to put it under the MINA umbrella as it is something that is
>> commonly needed by anyone implementing a network protocol. But I can
>> also see an abstract between the dns implementation and MINA that would
>> make it possible to use it as a dns client utilizing different network
>> layers, like Grizzly or some other framework. Because as much as I do
>> love MINA (it's just so dang simple to use!), it would be nice to have a
>> single dns API that people can use regardless of what they want to use
>> for their own networking layer.
>>
>
> I agree.
>
>
>>>>> IMHO it is much better to start using the dnsjava objects for
>>>>> encoding/decoding as a start also because it is much more stable than
>>>>> the directory code.
>>>>>
>>>>> Stefano
>>>>>
>>>>>
>>>> I wouldn't mind lifting ideas and workarounds from the dnsjava code, but
>>>> I don't think we need to go so far as to take all their base classes.
>>>> One problem that I remember seeing with how they do their
>>>> decoding/encoding is that it is actually a part of the message object,
>>>> which does not seem like a good idea to me. One thing that appealed to
>>>> me about the way Enrique did the base objects in protocol-dns is that
>>>> the Message object and various record types are actually Value
>>>> Objects. This makes a lot of sense. Once constructed they should
>>>> never change.
>>>>
>>>>
>>> I think this also applies to dnsjava objects: they ARE value object.
>>> IMHO we can refactor them, we could also extract parsing into codec
>>> classes but I still think that refactoring from dnsjava is much better
>>> than starting from scratch.
>>>
>>>
>> Some of the dnsjava objects are Value Objects and some aren't. For
>> instance, a Message object can be modified anytime during it's lifetime,
>> but it looks like Records are Value Objects. But that's a minor detail
>> that could be worked out. And refactoring is fun, so count me in if we
>> can get consent.
>>
>
> I agree: refactoring is the best part if you have unit tests to prove
> you did everything right ;-)
>
>
It looks like dnsjava has a pretty comprehensive set of unit tests, so
no problem there.
>> I don't know what the details should be. As of this point I'm not an
>> ASF committer so maybe I should just work on it until I get something
>> going and then put it up somewhere I've got access and we can move it
>> into Apache at some point in the future.
>>
>
> You should start sending the CCLA/ICLA via FAX to the ASF, so that it
> will be more easy later to get you on a repository :-)
>
I'll do that, thanks.
> At the moment here is the people that show interest contributing to this
> dns library project:
> Julien Vermillard: directory and mina projects
> Richard Wallace: not an ASF committer
> Stefano Bagnara: james project
> Norman Maurer: james project
>
> As Apache JAMES PMC member I can only tell that probably JAMES is not
> the place for this dns project as we would be users for this library but
> DNS is not so related to email that is JAMES primary topic.
>
> Now I think that the Mina PMC has to decide whether this work should be
> started in a MINA sandbox or we should better request a Lab for it.
>
> For my experience it is better to avoid working offline and instead
> start working directly in an ASF repository, so it is much more clear to
> everyone who committed each code and where every piece of code has been
> contributed from.
>
> The main problem is that Apache Labs does not allow to create new ASF
> committers, so to have you aboard our only chance is to find a space in
> another project (MINA?).
>
> Stefano
>
>
Re: DNS Protocol (Was: DHCP Protocol Home)
Posted by Stefano Bagnara <ap...@bago.org>.
Richard Wallace ha scritto:
> Stefano Bagnara wrote:
>> In particular I don't have any DNS specific knowledge and I really would
>> like to change as few as possible from a working and widely adopted
>> implentation :-)
>>
>>
> I agree we should reuse what we can. I saw you have talked with both
> authors of dnsjava and dnsjnio, did you get the feeling from Brian that
> he would be willing to contribute his code to the Apache project? I
> know it's already BSD, but I'd feel alot better about reusing his code
> if he were a willing contributor.
My feeling about Alex (dnsjnio) is that he is willing to license his
code under more permissive license, but we never talked about
contributing to ASF. Instead I never talked to Brian about contributing
code to ASF.
I think Brian is a lot conservative on dnsjava so I don't think he is
willing to work on enhancement/fork of his library under the ASF umbrella.
If you instead talk about trying to get a "software grant" from Brian to
the ASF for the copyrights of dnsjava I don't have idea about what's
Brian opinion (and if he is has exclusive copyrights on that code), so
maybe you should anyway consider the BSD license terms as our way.
IANAL and I don't often get most "subtle" license issues, but if I
understood it we can take the BSD code, we should only take care of not
using the DNSJAVA/XBILL names inside our code and maybe add a reference
in NOTICE to tell that some of our code is based on DNSJAVA, right?
>>>> If we reuse basic classes from dnsjava we can take the TSIG and other
>>>> dns supporting tools as is from the dnsjava library.
>>>>
>>> I don't think we necessarily need to take the base classes from
>>> dnsjava. There is already a good set of base classes in
>>> protocol-dns. Looking at how other projects support the protocol and
>>> what workarounds
>>> they've had to implement is a good idea.
>>>
>>
>> Well, I was simply stating my goals. I won't be able to implement the
>> full library starting from the protocol-dns sandbox.
>> What I can try to do is to start from dnsjava and provide mina based
>> transport and a mina based lookup class (that I already have based on
>> dnsjnio).
>>
>>
> The more I think of this the more I'm starting to like the idea of
> refactoring dnsjava into something more MINA based. I wouldn't mind
> taking a stab at that. I'm wondering what Enrique's take is on this,
> since he's the original author of protocol-dns (and many of the other
> protocol- implementations in Directory).
I think protocol-dns is much more lightweight than dnsjava, but it is
also very limited to exporting directory data via the DNS protocol,
without DNSSEC, without recursion and so on.
Anyway I think Enrique comments could help: is Enrique subscribed to
MINA list or should we CC again to directory?
>>>> I just want to add asynchronous support. I already have it in
>>>> dnsjnio+dnsjava but I don't like to depend on dnsjava and dnsjnio only
>>>> because of their licensing (dnsjnio is MPL) and release workflow
>>>> (dnsjava author is not so reactive applying even the smallest patch).
>>>>
>>>> Furthermore the current dns project has dependencies on shared-protocol
>>>> and other directory specific modules I don't even care of
>>>> understanding/compiling.
>>>>
>>> This is one complaint I had as well. I would definitely like to see a
>>> TLP called Apache DNS that produces a client and server. One option for
>>> the server could be to plugin to the Apache Directory for doing
>>> resolutions, but there definitely needs to be a greater level of
>>> abstraction than there is now.
>>>
>>
>> IMHO MINA is the best place for a dns library: the main cause is that
>> most protocols require dns-lookups to work, so a MINA developer would
>> probably use also dns resolution.
>> I bet most people using MINA still rely on synchronous dnsjava or
>> synchronous java.net lookups and asynschronous dns lookups should be
>> part of the standard mina distribution.
>>
> I think that it makes sense to start it as a subproject of some existing
> project until it gets a community of its own. And I think it does make
> more sense to put it under the MINA umbrella as it is something that is
> commonly needed by anyone implementing a network protocol. But I can
> also see an abstract between the dns implementation and MINA that would
> make it possible to use it as a dns client utilizing different network
> layers, like Grizzly or some other framework. Because as much as I do
> love MINA (it's just so dang simple to use!), it would be nice to have a
> single dns API that people can use regardless of what they want to use
> for their own networking layer.
I agree.
>>>> IMHO it is much better to start using the dnsjava objects for
>>>> encoding/decoding as a start also because it is much more stable than
>>>> the directory code.
>>>>
>>>> Stefano
>>>>
>>> I wouldn't mind lifting ideas and workarounds from the dnsjava code, but
>>> I don't think we need to go so far as to take all their base classes.
>>> One problem that I remember seeing with how they do their
>>> decoding/encoding is that it is actually a part of the message object,
>>> which does not seem like a good idea to me. One thing that appealed to
>>> me about the way Enrique did the base objects in protocol-dns is that
>>> the Message object and various record types are actually Value
>>> Objects. This makes a lot of sense. Once constructed they should
>>> never change.
>>>
>> I think this also applies to dnsjava objects: they ARE value object.
>> IMHO we can refactor them, we could also extract parsing into codec
>> classes but I still think that refactoring from dnsjava is much better
>> than starting from scratch.
>>
> Some of the dnsjava objects are Value Objects and some aren't. For
> instance, a Message object can be modified anytime during it's lifetime,
> but it looks like Records are Value Objects. But that's a minor detail
> that could be worked out. And refactoring is fun, so count me in if we
> can get consent.
I agree: refactoring is the best part if you have unit tests to prove
you did everything right ;-)
> I don't know what the details should be. As of this point I'm not an
> ASF committer so maybe I should just work on it until I get something
> going and then put it up somewhere I've got access and we can move it
> into Apache at some point in the future.
You should start sending the CCLA/ICLA via FAX to the ASF, so that it
will be more easy later to get you on a repository :-)
At the moment here is the people that show interest contributing to this
dns library project:
Julien Vermillard: directory and mina projects
Richard Wallace: not an ASF committer
Stefano Bagnara: james project
Norman Maurer: james project
As Apache JAMES PMC member I can only tell that probably JAMES is not
the place for this dns project as we would be users for this library but
DNS is not so related to email that is JAMES primary topic.
Now I think that the Mina PMC has to decide whether this work should be
started in a MINA sandbox or we should better request a Lab for it.
For my experience it is better to avoid working offline and instead
start working directly in an ASF repository, so it is much more clear to
everyone who committed each code and where every piece of code has been
contributed from.
The main problem is that Apache Labs does not allow to create new ASF
committers, so to have you aboard our only chance is to find a space in
another project (MINA?).
Stefano
Re: DNS Protocol (Was: DHCP Protocol Home)
Posted by Richard Wallace <rw...@thewallacepack.net>.
Stefano Bagnara wrote:
> Richard Wallace ha scritto:
>
>> Stefano Bagnara wrote:
>>
>>> My interest is mainly to build a DNS *client* and not a server.
>>>
>>>
>> I think part of the idea is that a good MINA protocol provider can be
>> used to build both a client and a server. In reality, all the client
>> would be is a thin wrapper around MINA and the protocol provider.
>>
>
> Well, this is partly true: in fact the current dns protocol in directory
> project implements only encoders. To create a recursive dns server you
> will need anyway the dns client capabilities and even more (zone
> transfer, as an example)
>
>
It doesn't only implement encoders. It also supports some of the more
common decoders. Not for as many record types as encoders, but there
are some there. And yes, a dns server would naturally have to be able
to act as a full dns client itself. But that is still functionality
that would be provided by a dns client project that the dns server would
make use of.
>>> I had a look at directory-dns project few months ago (and I see there
>>> have been no changes in the mean time). It only contains very partial
>>> reusable code for a dns client and it misses a lot of needed code.
>>>
>>>
>>>
>> What do you feel is missing? There are some record types that are not
>> yet supported, but adding these wouldn't be a big issue. Support for
>> DNSSEC and caching would be the biggest hurdles to tackle in creating a
>> really good client.
>>
>
> Exactly. DNSSEC and Caching.. they are already implemented and working
> find in dnsjava and if we use the dnsjava message data structure we get
> them for free (dnsjava is BSD), so why should we reinvent the wheel?
>
> In particular I don't have any DNS specific knowledge and I really would
> like to change as few as possible from a working and widely adopted
> implentation :-)
>
>
I agree we should reuse what we can. I saw you have talked with both
authors of dnsjava and dnsjnio, did you get the feeling from Brian that
he would be willing to contribute his code to the Apache project? I
know it's already BSD, but I'd feel alot better about reusing his code
if he were a willing contributor.
>>> If we reuse basic classes from dnsjava we can take the TSIG and other
>>> dns supporting tools as is from the dnsjava library.
>>>
>>>
>> I don't think we necessarily need to take the base classes from
>> dnsjava. There is already a good set of base classes in protocol-dns.
>> Looking at how other projects support the protocol and what workarounds
>> they've had to implement is a good idea.
>>
>
> Well, I was simply stating my goals. I won't be able to implement the
> full library starting from the protocol-dns sandbox.
> What I can try to do is to start from dnsjava and provide mina based
> transport and a mina based lookup class (that I already have based on
> dnsjnio).
>
>
The more I think of this the more I'm starting to like the idea of
refactoring dnsjava into something more MINA based. I wouldn't mind
taking a stab at that. I'm wondering what Enrique's take is on this,
since he's the original author of protocol-dns (and many of the other
protocol- implementations in Directory).
>>> I just want to add asynchronous support. I already have it in
>>> dnsjnio+dnsjava but I don't like to depend on dnsjava and dnsjnio only
>>> because of their licensing (dnsjnio is MPL) and release workflow
>>> (dnsjava author is not so reactive applying even the smallest patch).
>>>
>>> Furthermore the current dns project has dependencies on shared-protocol
>>> and other directory specific modules I don't even care of
>>> understanding/compiling.
>>>
>>>
>> This is one complaint I had as well. I would definitely like to see a
>> TLP called Apache DNS that produces a client and server. One option for
>> the server could be to plugin to the Apache Directory for doing
>> resolutions, but there definitely needs to be a greater level of
>> abstraction than there is now.
>>
>
> IMHO MINA is the best place for a dns library: the main cause is that
> most protocols require dns-lookups to work, so a MINA developer would
> probably use also dns resolution.
> I bet most people using MINA still rely on synchronous dnsjava or
> synchronous java.net lookups and asynschronous dns lookups should be
> part of the standard mina distribution.
>
>
I think that it makes sense to start it as a subproject of some existing
project until it gets a community of its own. And I think it does make
more sense to put it under the MINA umbrella as it is something that is
commonly needed by anyone implementing a network protocol. But I can
also see an abstract between the dns implementation and MINA that would
make it possible to use it as a dns client utilizing different network
layers, like Grizzly or some other framework. Because as much as I do
love MINA (it's just so dang simple to use!), it would be nice to have a
single dns API that people can use regardless of what they want to use
for their own networking layer.
>>> IMHO it is much better to start using the dnsjava objects for
>>> encoding/decoding as a start also because it is much more stable than
>>> the directory code.
>>>
>>> Stefano
>>>
>>>
>> I wouldn't mind lifting ideas and workarounds from the dnsjava code, but
>> I don't think we need to go so far as to take all their base classes.
>> One problem that I remember seeing with how they do their
>> decoding/encoding is that it is actually a part of the message object,
>> which does not seem like a good idea to me. One thing that appealed to
>> me about the way Enrique did the base objects in protocol-dns is that
>> the Message object and various record types are actually Value Objects.
>> This makes a lot of sense. Once constructed they should never change.
>>
>
> I think this also applies to dnsjava objects: they ARE value object.
> IMHO we can refactor them, we could also extract parsing into codec
> classes but I still think that refactoring from dnsjava is much better
> than starting from scratch.
>
Some of the dnsjava objects are Value Objects and some aren't. For
instance, a Message object can be modified anytime during it's lifetime,
but it looks like Records are Value Objects. But that's a minor detail
that could be worked out. And refactoring is fun, so count me in if we
can get consent.
> Again, if we have someone (you?) that will take care or unit testing the
> whole message structure beans, encoding and decoding, supporting DNSSEC
> and CACHE and mantain it then I will change my mind ;-) I just don't
> want to start something bigger than me. I'm a dns user, not a dns
> developer, and I'm just trying to solve issues in my mina based
> applications and dns lookups.
>
>
>> While I wouldn't consider myself an "expert" on DNS, I did spend a
>> considerable bit of time looking at the specs and looking at the code
>> for protocol-dns and dnsjava. I have considered starting a new project
>> based on protocol-dns and trying to properly abstract some of the
>> dependencies that it has on the Directory sub-projects as well as trying
>> to complete support for as many of the record types as I can. I had
>> also planned on tackling the caching issue and a few other client
>> issues, like a nice dig-like wrapper around MINA and the protocol
>> provider. This is actually something I was planning to take another
>> look at again in the next few days so this topic has come up at a
>> perfect time for me. I'm willing to throw my hat and time into the ring
>> if there is enough interest. Otherwise it might just be something I
>> work on in private until I get something I'm happy with and release it
>> out to the community.
>>
>> Rich
>>
>
> That would be great. Do you think we should move to an apache lab, we
> should use a sandbox inside mina or what else?
> I would avoid having this dns stuff in directory, and I'm not committer
> to MINA, so maybe an apache lab would be the best thing.
> Maybe a sandbox folder in MINA where every ASF committer can write would
> be the best solution (maven TLP did something similar to let other ASF
> committers to sandbox their m2 plugins)
>
> Stefano
>
>
I don't know what the details should be. As of this point I'm not an
ASF committer so maybe I should just work on it until I get something
going and then put it up somewhere I've got access and we can move it
into Apache at some point in the future.
Rich
Re: DNS Protocol (Was: DHCP Protocol Home)
Posted by Stefano Bagnara <ap...@bago.org>.
Richard Wallace ha scritto:
> Stefano Bagnara wrote:
>> My interest is mainly to build a DNS *client* and not a server.
>>
> I think part of the idea is that a good MINA protocol provider can be
> used to build both a client and a server. In reality, all the client
> would be is a thin wrapper around MINA and the protocol provider.
Well, this is partly true: in fact the current dns protocol in directory
project implements only encoders. To create a recursive dns server you
will need anyway the dns client capabilities and even more (zone
transfer, as an example)
>> I had a look at directory-dns project few months ago (and I see there
>> have been no changes in the mean time). It only contains very partial
>> reusable code for a dns client and it misses a lot of needed code.
>>
>>
> What do you feel is missing? There are some record types that are not
> yet supported, but adding these wouldn't be a big issue. Support for
> DNSSEC and caching would be the biggest hurdles to tackle in creating a
> really good client.
Exactly. DNSSEC and Caching.. they are already implemented and working
find in dnsjava and if we use the dnsjava message data structure we get
them for free (dnsjava is BSD), so why should we reinvent the wheel?
In particular I don't have any DNS specific knowledge and I really would
like to change as few as possible from a working and widely adopted
implentation :-)
>> If we reuse basic classes from dnsjava we can take the TSIG and other
>> dns supporting tools as is from the dnsjava library.
>>
> I don't think we necessarily need to take the base classes from
> dnsjava. There is already a good set of base classes in protocol-dns.
> Looking at how other projects support the protocol and what workarounds
> they've had to implement is a good idea.
Well, I was simply stating my goals. I won't be able to implement the
full library starting from the protocol-dns sandbox.
What I can try to do is to start from dnsjava and provide mina based
transport and a mina based lookup class (that I already have based on
dnsjnio).
>> I just want to add asynchronous support. I already have it in
>> dnsjnio+dnsjava but I don't like to depend on dnsjava and dnsjnio only
>> because of their licensing (dnsjnio is MPL) and release workflow
>> (dnsjava author is not so reactive applying even the smallest patch).
>>
>> Furthermore the current dns project has dependencies on shared-protocol
>> and other directory specific modules I don't even care of
>> understanding/compiling.
>>
> This is one complaint I had as well. I would definitely like to see a
> TLP called Apache DNS that produces a client and server. One option for
> the server could be to plugin to the Apache Directory for doing
> resolutions, but there definitely needs to be a greater level of
> abstraction than there is now.
IMHO MINA is the best place for a dns library: the main cause is that
most protocols require dns-lookups to work, so a MINA developer would
probably use also dns resolution.
I bet most people using MINA still rely on synchronous dnsjava or
synchronous java.net lookups and asynschronous dns lookups should be
part of the standard mina distribution.
>> IMHO it is much better to start using the dnsjava objects for
>> encoding/decoding as a start also because it is much more stable than
>> the directory code.
>>
>> Stefano
>>
>
> I wouldn't mind lifting ideas and workarounds from the dnsjava code, but
> I don't think we need to go so far as to take all their base classes.
> One problem that I remember seeing with how they do their
> decoding/encoding is that it is actually a part of the message object,
> which does not seem like a good idea to me. One thing that appealed to
> me about the way Enrique did the base objects in protocol-dns is that
> the Message object and various record types are actually Value Objects.
> This makes a lot of sense. Once constructed they should never change.
I think this also applies to dnsjava objects: they ARE value object.
IMHO we can refactor them, we could also extract parsing into codec
classes but I still think that refactoring from dnsjava is much better
than starting from scratch.
Again, if we have someone (you?) that will take care or unit testing the
whole message structure beans, encoding and decoding, supporting DNSSEC
and CACHE and mantain it then I will change my mind ;-) I just don't
want to start something bigger than me. I'm a dns user, not a dns
developer, and I'm just trying to solve issues in my mina based
applications and dns lookups.
> While I wouldn't consider myself an "expert" on DNS, I did spend a
> considerable bit of time looking at the specs and looking at the code
> for protocol-dns and dnsjava. I have considered starting a new project
> based on protocol-dns and trying to properly abstract some of the
> dependencies that it has on the Directory sub-projects as well as trying
> to complete support for as many of the record types as I can. I had
> also planned on tackling the caching issue and a few other client
> issues, like a nice dig-like wrapper around MINA and the protocol
> provider. This is actually something I was planning to take another
> look at again in the next few days so this topic has come up at a
> perfect time for me. I'm willing to throw my hat and time into the ring
> if there is enough interest. Otherwise it might just be something I
> work on in private until I get something I'm happy with and release it
> out to the community.
>
> Rich
That would be great. Do you think we should move to an apache lab, we
should use a sandbox inside mina or what else?
I would avoid having this dns stuff in directory, and I'm not committer
to MINA, so maybe an apache lab would be the best thing.
Maybe a sandbox folder in MINA where every ASF committer can write would
be the best solution (maven TLP did something similar to let other ASF
committers to sandbox their m2 plugins)
Stefano
Re: DNS Protocol (Was: DHCP Protocol Home)
Posted by Richard Wallace <rw...@thewallacepack.net>.
Stefano Bagnara wrote:
> Alex Karasulu ha scritto:
>
>> What about working on the DNS protocol provider we have in Directory?
>> Let's
>> grow community around this. The barrier of entry to existing ASF
>> committers
>> from
>> MINA should be minimal.
>>
>> What's the benefit of starting yet another DNS server effort? Furthermore
>> are there
>> issues with the DNS PP in Directory?
>>
>
> My interest is mainly to build a DNS *client* and not a server.
>
I think part of the idea is that a good MINA protocol provider can be
used to build both a client and a server. In reality, all the client
would be is a thin wrapper around MINA and the protocol provider.
> I had a look at directory-dns project few months ago (and I see there
> have been no changes in the mean time). It only contains very partial
> reusable code for a dns client and it misses a lot of needed code.
>
>
What do you feel is missing? There are some record types that are not
yet supported, but adding these wouldn't be a big issue. Support for
DNSSEC and caching would be the biggest hurdles to tackle in creating a
really good client.
> If we reuse basic classes from dnsjava we can take the TSIG and other
> dns supporting tools as is from the dnsjava library.
>
>
I don't think we necessarily need to take the base classes from
dnsjava. There is already a good set of base classes in protocol-dns.
Looking at how other projects support the protocol and what workarounds
they've had to implement is a good idea.
> I just want to add asynchronous support. I already have it in
> dnsjnio+dnsjava but I don't like to depend on dnsjava and dnsjnio only
> because of their licensing (dnsjnio is MPL) and release workflow
> (dnsjava author is not so reactive applying even the smallest patch).
>
> Furthermore the current dns project has dependencies on shared-protocol
> and other directory specific modules I don't even care of
> understanding/compiling.
>
This is one complaint I had as well. I would definitely like to see a
TLP called Apache DNS that produces a client and server. One option for
the server could be to plugin to the Apache Directory for doing
resolutions, but there definitely needs to be a greater level of
abstraction than there is now.
> IMHO it is much better to start using the dnsjava objects for
> encoding/decoding as a start also because it is much more stable than
> the directory code.
>
> Stefano
>
I wouldn't mind lifting ideas and workarounds from the dnsjava code, but
I don't think we need to go so far as to take all their base classes.
One problem that I remember seeing with how they do their
decoding/encoding is that it is actually a part of the message object,
which does not seem like a good idea to me. One thing that appealed to
me about the way Enrique did the base objects in protocol-dns is that
the Message object and various record types are actually Value Objects.
This makes a lot of sense. Once constructed they should never change.
While I wouldn't consider myself an "expert" on DNS, I did spend a
considerable bit of time looking at the specs and looking at the code
for protocol-dns and dnsjava. I have considered starting a new project
based on protocol-dns and trying to properly abstract some of the
dependencies that it has on the Directory sub-projects as well as trying
to complete support for as many of the record types as I can. I had
also planned on tackling the caching issue and a few other client
issues, like a nice dig-like wrapper around MINA and the protocol
provider. This is actually something I was planning to take another
look at again in the next few days so this topic has come up at a
perfect time for me. I'm willing to throw my hat and time into the ring
if there is enough interest. Otherwise it might just be something I
work on in private until I get something I'm happy with and release it
out to the community.
Rich
Re: DNS Protocol (Was: DHCP Protocol Home)
Posted by Stefano Bagnara <ap...@bago.org>.
Alex Karasulu ha scritto:
> What about working on the DNS protocol provider we have in Directory?
> Let's
> grow community around this. The barrier of entry to existing ASF
> committers
> from
> MINA should be minimal.
>
> What's the benefit of starting yet another DNS server effort? Furthermore
> are there
> issues with the DNS PP in Directory?
My interest is mainly to build a DNS *client* and not a server.
I had a look at directory-dns project few months ago (and I see there
have been no changes in the mean time). It only contains very partial
reusable code for a dns client and it misses a lot of needed code.
If we reuse basic classes from dnsjava we can take the TSIG and other
dns supporting tools as is from the dnsjava library.
I just want to add asynchronous support. I already have it in
dnsjnio+dnsjava but I don't like to depend on dnsjava and dnsjnio only
because of their licensing (dnsjnio is MPL) and release workflow
(dnsjava author is not so reactive applying even the smallest patch).
Furthermore the current dns project has dependencies on shared-protocol
and other directory specific modules I don't even care of
understanding/compiling.
IMHO it is much better to start using the dnsjava objects for
encoding/decoding as a start also because it is much more stable than
the directory code.
Stefano
Re: DNS Protocol (Was: DHCP Protocol Home)
Posted by Alex Karasulu <ak...@apache.org>.
Hi Michael,
On 6/12/07, Michael Mealling <mi...@refactored-networks.com> wrote:
>
> Alex,
> I know that in my situation I needed a DNS server that I could easily
> modify and that didn't come with a lot of extras. What I was building
> was a custom synthesizing DNS server for VOIP applications which means I
> was creating NAPTR records based on business rules. I modeled much of
> what I did directly on the provider in the Directory project but much of
> what I needed wasn't there (SNMP agent, query statistics, custom
> business rules, etc). (BTW, personal opinion: SNMP must die a quick and
> painful death)
Hehe I'm there right with you! Ready to shoot it :).
I think people who are looking at something like this fall into three
> camps:
>
> 1) People who want a DNS server to replace BIND or some other instance
> to do what DNS servers do.
Aye! Also I think with ADS we can do some slick things with dynamic DNS and
triggers.
2) A well done and maintained set of async DNS libraries for DNS queries
Yes this is something that would be nice to have.
3) A DNS server that is capable of high query througput but can easily
> modified to handle non-standard DNS applications (synthesized zones,
> synthesized records, smart caching, etc)
Yes this is something my employer has expressed interest in. They are
pretty
excited in the possibilities with LDAP virtualization and what this would
mean
for DNS in terms of synthesized zones and records. They host a lot of sites
and which require some interesting fail over scenarios. Triggers, stored
procedures
and views in LDAP will nicely facilitate these needs when the DNS server
backs
it's records in a read optimized and search-able directory.
IMHO, the PP in Directory handles #1 but includes a lot of things that
> most enterprises will have other components to handle. For example,
> where I'm working now the people who run DNS and the people who run LDAP
> are in completely different departments, with different standards and
> different data centers. Having LDAP and DNS in the same app does them no
> good.
The LDAP protocol can be turned of and just the store can be used. Really
this
just gives you a bigger advantage over dealing with flat files or some kind
of
XML. You get the indices and fast search/lookup capabilities with minimal
overhead. Basically the default store is backed by JDBM (B+Tree) files.
Also
if you don't want that we can make it so a store interface can be used and
you can use flat files. We can separate LDAP from DNS easily with the
proper
store interface abstraction.
Just some thoughts from having done it already...
Aye. My concern is to try to build community around DNS in general and I
understand
our Light weight [DAP] may not be LW enough. In which case I think it's
worth considering
how we can make the store more pluggable or even lighter :). Sometimes it's
just a
matter of not needing the search capabilities and wanting to step away from
the
LDAP DN syntax and definitely can appreciate that.
However if people want to just start over that's their right it would just
be a waste
IMHO if we cannot work out the issues. Regardless tho there is nothing that
says two projects on the same protocol cannot co-exist at Apache. It might
even
be better in the end. Hope the community picks the best solution for
everyone.
Regards,
Alex
Re: DNS Protocol (Was: DHCP Protocol Home)
Posted by Trustin Lee <tr...@gmail.com>.
On 6/12/07, Alex Karasulu <ak...@apache.org> wrote:
> Hey this is great. We can simply just define the proper store interfaces as
> you have
> done. I think we can achieve what you need but really if you need to start
> a lab project
> for it do so. If you want to help out with the Directory DNS project then
> you're welcome
> to just commit to it. I guess you still have commit rights to Directory
> since when MINA
> was hosted there.
>
> Also we should bring up all the ADS interfaces to MINA 2.0. I think this is
>
> good for ADS and good for MINA. I spoke to some of the directory peeps
> about this
> and we're ready to do it. Trustin told me MINA 2.0 may have a significant
> performance impact as well. If so we should make the move and start testing
> with
> it. Directory and MINA have good effects on one another that benefits the
> entire
> community at large.
Please note MINA 2.0 has very many issues to resolve. I think it's
not even close to its first milestone because of a few critical issues
to be fixed. I never recommend you to migrate to MINA 2.0 just
because of DNS.
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
Re: DNS Protocol (Was: DHCP Protocol Home)
Posted by Alex Karasulu <ak...@apache.org>.
Hey this is great. We can simply just define the proper store interfaces as
you have
done. I think we can achieve what you need but really if you need to start
a lab project
for it do so. If you want to help out with the Directory DNS project then
you're welcome
to just commit to it. I guess you still have commit rights to Directory
since when MINA
was hosted there.
Also we should bring up all the ADS interfaces to MINA 2.0. I think this is
good for ADS and good for MINA. I spoke to some of the directory peeps
about this
and we're ready to do it. Trustin told me MINA 2.0 may have a significant
performance impact as well. If so we should make the move and start testing
with
it. Directory and MINA have good effects on one another that benefits the
entire
community at large.
Cheers,
Alex
On 6/12/07, Julien Vermillard <jv...@archean.fr> wrote:
>
> Hi Alex
>
> I started modifying ADS DNS provider for using MINA 2.0.
> I'm working on embedded applications and I can't afford much
> dependencies and extra code (64 MB RAM SBC running 24/7 and a big stick
> for beating me if the customer need to reboot it).
> So I choosed to get rid off all the ADS/LDAP/JNDI part and providing my
> own very simple DataStore for resolving inet address (who actualy
> generate corrupted DNS reply :( ).
>
> I just wanted MINA 2.0 compatibility, small footprint, and just a small
> server for resolving "IN A" from VoIP devices. I'm not sure those needs
> fits with ADS DNS provider. I try to make it working but for the moment
> I'm on other urgent subjet.
>
> Julien
>
> Le mardi 12 juin 2007 à 09:41 -0400, Michael Mealling a écrit :
> > Alex,
> > I know that in my situation I needed a DNS server that I could easily
> > modify and that didn't come with a lot of extras. What I was building
> > was a custom synthesizing DNS server for VOIP applications which means I
> > was creating NAPTR records based on business rules. I modeled much of
> > what I did directly on the provider in the Directory project but much of
> > what I needed wasn't there (SNMP agent, query statistics, custom
> > business rules, etc). (BTW, personal opinion: SNMP must die a quick and
> > painful death)
> > I think people who are looking at something like this fall into three
> > camps:
> >
> > 1) People who want a DNS server to replace BIND or some other instance
> > to do what DNS servers do.
> >
> > 2) A well done and maintained set of async DNS libraries for DNS queries
> >
> > 3) A DNS server that is capable of high query througput but can easily
> > modified to handle non-standard DNS applications (synthesized zones,
> > synthesized records, smart caching, etc)
> >
> > IMHO, the PP in Directory handles #1 but includes a lot of things that
> > most enterprises will have other components to handle. For example,
> > where I'm working now the people who run DNS and the people who run LDAP
> > are in completely different departments, with different standards and
> > different data centers. Having LDAP and DNS in the same app does them no
> > good.
> >
> > Just some thoughts from having done it already...
> >
> > -MM
> >
> > Alex Karasulu wrote:
> > > What about working on the DNS protocol provider we have in Directory?
> > > Let's
> > > grow community around this. The barrier of entry to existing ASF
> > > committers
> > > from
> > > MINA should be minimal.
> > >
> > > What's the benefit of starting yet another DNS server
> effort? Furthermore
> > > are there
> > > issues with the DNS PP in Directory?
> >
> >
>
>
Re: DNS Protocol (Was: DHCP Protocol Home)
Posted by Julien Vermillard <jv...@archean.fr>.
Hi Alex
I started modifying ADS DNS provider for using MINA 2.0.
I'm working on embedded applications and I can't afford much
dependencies and extra code (64 MB RAM SBC running 24/7 and a big stick
for beating me if the customer need to reboot it).
So I choosed to get rid off all the ADS/LDAP/JNDI part and providing my
own very simple DataStore for resolving inet address (who actualy
generate corrupted DNS reply :( ).
I just wanted MINA 2.0 compatibility, small footprint, and just a small
server for resolving "IN A" from VoIP devices. I'm not sure those needs
fits with ADS DNS provider. I try to make it working but for the moment
I'm on other urgent subjet.
Julien
Le mardi 12 juin 2007 à 09:41 -0400, Michael Mealling a écrit :
> Alex,
> I know that in my situation I needed a DNS server that I could easily
> modify and that didn't come with a lot of extras. What I was building
> was a custom synthesizing DNS server for VOIP applications which means I
> was creating NAPTR records based on business rules. I modeled much of
> what I did directly on the provider in the Directory project but much of
> what I needed wasn't there (SNMP agent, query statistics, custom
> business rules, etc). (BTW, personal opinion: SNMP must die a quick and
> painful death)
> I think people who are looking at something like this fall into three
> camps:
>
> 1) People who want a DNS server to replace BIND or some other instance
> to do what DNS servers do.
>
> 2) A well done and maintained set of async DNS libraries for DNS queries
>
> 3) A DNS server that is capable of high query througput but can easily
> modified to handle non-standard DNS applications (synthesized zones,
> synthesized records, smart caching, etc)
>
> IMHO, the PP in Directory handles #1 but includes a lot of things that
> most enterprises will have other components to handle. For example,
> where I'm working now the people who run DNS and the people who run LDAP
> are in completely different departments, with different standards and
> different data centers. Having LDAP and DNS in the same app does them no
> good.
>
> Just some thoughts from having done it already...
>
> -MM
>
> Alex Karasulu wrote:
> > What about working on the DNS protocol provider we have in Directory?
> > Let's
> > grow community around this. The barrier of entry to existing ASF
> > committers
> > from
> > MINA should be minimal.
> >
> > What's the benefit of starting yet another DNS server effort? Furthermore
> > are there
> > issues with the DNS PP in Directory?
>
>
Re: DNS Protocol (Was: DHCP Protocol Home)
Posted by Michael Mealling <mi...@refactored-networks.com>.
Alex,
I know that in my situation I needed a DNS server that I could easily
modify and that didn't come with a lot of extras. What I was building
was a custom synthesizing DNS server for VOIP applications which means I
was creating NAPTR records based on business rules. I modeled much of
what I did directly on the provider in the Directory project but much of
what I needed wasn't there (SNMP agent, query statistics, custom
business rules, etc). (BTW, personal opinion: SNMP must die a quick and
painful death)
I think people who are looking at something like this fall into three
camps:
1) People who want a DNS server to replace BIND or some other instance
to do what DNS servers do.
2) A well done and maintained set of async DNS libraries for DNS queries
3) A DNS server that is capable of high query througput but can easily
modified to handle non-standard DNS applications (synthesized zones,
synthesized records, smart caching, etc)
IMHO, the PP in Directory handles #1 but includes a lot of things that
most enterprises will have other components to handle. For example,
where I'm working now the people who run DNS and the people who run LDAP
are in completely different departments, with different standards and
different data centers. Having LDAP and DNS in the same app does them no
good.
Just some thoughts from having done it already...
-MM
Alex Karasulu wrote:
> What about working on the DNS protocol provider we have in Directory?
> Let's
> grow community around this. The barrier of entry to existing ASF
> committers
> from
> MINA should be minimal.
>
> What's the benefit of starting yet another DNS server effort? Furthermore
> are there
> issues with the DNS PP in Directory?
--
Michael Mealling Refactored Networks, LLC
CEO & President 1645 Old Hwy 41
Office: +1-678-581-9656 Suite 112, Box 138
Cell: +1-678-640-6884 Kennesaw, GA 30152
http://refactored-networks.com/
Re: DNS Protocol (Was: DHCP Protocol Home)
Posted by Alex Karasulu <ak...@apache.org>.
What about working on the DNS protocol provider we have in Directory? Let's
grow community around this. The barrier of entry to existing ASF committers
from
MINA should be minimal.
What's the benefit of starting yet another DNS server effort? Furthermore
are there
issues with the DNS PP in Directory?
Alex
On 6/12/07, Norman <no...@apache.org> wrote:
>
> Julien Vermillard schrieb:
> > Le mardi 12 juin 2007 Ã 10:17 +0200, Stefano Bagnara a Ã(c)crit :
> >
> >> 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?
> >>
> >> Stefano
> >>
> >
> > Hi,
> > I'm interested in a lightweight DNS server, I don't know much the DNS
> > byte level protocol, but I can help for the MINA part :)
> >
> > Julien
> >
> >
>
> I'm intressted too ( maybe mainly because we need it anyway in jspf ;-)
> ). So I will try to help you too . Maybe a apache lab whould be a could
> starting place.
>
> bye
> Norman
>
Re: DNS Protocol (Was: DHCP Protocol Home)
Posted by Norman <no...@apache.org>.
Julien Vermillard schrieb:
> Le mardi 12 juin 2007 à 10:17 +0200, Stefano Bagnara a écrit :
>
>> 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?
>>
>> Stefano
>>
>
> Hi,
> I'm interested in a lightweight DNS server, I don't know much the DNS
> byte level protocol, but I can help for the MINA part :)
>
> Julien
>
>
I'm intressted too ( maybe mainly because we need it anyway in jspf ;-)
). So I will try to help you too . Maybe a apache lab whould be a could
starting place.
bye
Norman
Re: DNS Protocol (Was: DHCP Protocol Home)
Posted by Julien Vermillard <jv...@archean.fr>.
Le mardi 12 juin 2007 à 10:17 +0200, Stefano Bagnara a écrit :
> 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?
>
> Stefano
Hi,
I'm interested in a lightweight DNS server, I don't know much the DNS
byte level protocol, but I can help for the MINA part :)
Julien
Re: DNS Protocol (Was: DHCP Protocol Home)
Posted by 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
DNS Protocol (Was: DHCP Protocol Home)
Posted by Stefano Bagnara <ap...@bago.org>.
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?
Stefano
Re: DHCP Protocol Home (was: Re: [Vote] Sandboxing DHCP protocol)
Posted by Julien Vermillard <jv...@archean.fr>.
Le vendredi 15 juin 2007 à 08:33 +0200, Alex Karasulu a écrit :
> IMO MINA is the best place.right now. It does not matter where. We at
> Directory
> can reuse these light libraries and back it with LDAP using a custom store.
> It's
> really not a big deal so let's just get started. To continue discussing
> this would
> simply be bike shedding.
>
> Alex
>
Hi,
With Enrique help, I managed to run a dummy RecordStore for resolving
few A IN records on ADS DNS stack. Apparently Enrique found a bug in dns
records encoder (ADS TRUNK). For now, I'll try to got further and
propose fix for lesss ADS dependency and easier interface for making
custom RecordStore.
Julien
Re: DHCP Protocol Home (was: Re: [Vote] Sandboxing DHCP protocol)
Posted by Alex Karasulu <ak...@apache.org>.
IMO MINA is the best place.right now. It does not matter where. We at
Directory
can reuse these light libraries and back it with LDAP using a custom store.
It's
really not a big deal so let's just get started. To continue discussing
this would
simply be bike shedding.
Alex
On 6/14/07, Stefano Bagnara <ap...@bago.org> wrote:
>
> Emmanuel Lecharny ha scritto:
> >> Specialy french who allways like too disagree :)
> >
> > french like to argument ;)
>
> But Italians do it better.. ups, was it about argument? ;-)
>
> I'm very fine with recording the disagreement without requiring endless
> discussion. We are enough to let democracy (meritocracy) works around
> the disagreement when needed.
>
> >> I'm for waiting to see emerging code first, and discuss later. I'm
> >> actualy unable to manage to resolve a simple IN ADDR record with
> >> modified ADS DNS server, so I'm far of any usable server.
> >
> > Hmmm... It is supposed to work, but the fact is that we don't have a
> > lot of people knowing about DNS implementation in Directory... This
> > leads directly to the initial question : why don't move it to a place
> > where DNS aware people can handle questions and supply support ;)
> >
> > Emmanuel
>
> Can you suggest what/where such a place is?
>
> Stefano
>
>
Re: DHCP Protocol Home (was: Re: [Vote] Sandboxing DHCP protocol)
Posted by Stefano Bagnara <ap...@bago.org>.
Emmanuel Lecharny ha scritto:
>> Specialy french who allways like too disagree :)
>
> french like to argument ;)
But Italians do it better.. ups, was it about argument? ;-)
I'm very fine with recording the disagreement without requiring endless
discussion. We are enough to let democracy (meritocracy) works around
the disagreement when needed.
>> I'm for waiting to see emerging code first, and discuss later. I'm
>> actualy unable to manage to resolve a simple IN ADDR record with
>> modified ADS DNS server, so I'm far of any usable server.
>
> Hmmm... It is supposed to work, but the fact is that we don't have a
> lot of people knowing about DNS implementation in Directory... This
> leads directly to the initial question : why don't move it to a place
> where DNS aware people can handle questions and supply support ;)
>
> Emmanuel
Can you suggest what/where such a place is?
Stefano
Re: DHCP Protocol Home (was: Re: [Vote] Sandboxing DHCP protocol)
Posted by Emmanuel Lecharny <el...@gmail.com>.
> Specialy french who allways like too disagree :)
french like to argument ;)
>
> I'm for waiting to see emerging code first, and discuss later. I'm
> actualy unable to manage to resolve a simple IN ADDR record with
> modified ADS DNS server, so I'm far of any usable server.
Hmmm... It is supposed to work, but the fact is that we don't have a
lot of people knowing about DNS implementation in Directory... This
leads directly to the initial question : why don't move it to a place
where DNS aware people can handle questions and supply support ;)
Emmanuel
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: DHCP Protocol Home (was: Re: [Vote] Sandboxing DHCP protocol)
Posted by Julien Vermillard <jv...@archean.fr>.
Le jeudi 14 juin 2007 à 09:58 +0200, Emmanuel Lecharny a écrit :
> > My opinion was very related to DNS. IMHO DNS is different from FPT, HTTP
> > and SMTP because HTTP, FTP, SMTP clients (not protocol) will rely on DNS
> > for hostname resolution and not viceversa.
>
> I don't really think that make any difference. A protocol is a
> protocol, whatever it depends on. The fact that you need a DNS
> resolution when sending an Http request does not make DNS a
> 'different' protocol. Anyway, this is just a question of perception
> ...
> >
> > If a developer builds its own protocol to be used on internet, well, it
> > is very likely to need DNS somewhere.
> >
> > That's why I think that DNS belongs to MINA TLP.
>
> I don't see any connection between the fact that DNS is used by any
> other services and the idea that DNS protocol should belongs to MINA
> TLP...
Well if a convenient async DNS client can be made, it surely could be
shiped with MINA, but a full blown bind replacement is another story.
>
> I don't want to start a never ending discussion on this, so consider
> that the fact we don't agree does not mean I'm right :)
>
Specialy french who allways like too disagree :)
I'm for waiting to see emerging code first, and discuss later. I'm
actualy unable to manage to resolve a simple IN ADDR record with
modified ADS DNS server, so I'm far of any usable server.
Julien
Re: DHCP Protocol Home (was: Re: [Vote] Sandboxing DHCP protocol)
Posted by Emmanuel Lecharny <el...@gmail.com>.
> My opinion was very related to DNS. IMHO DNS is different from FPT, HTTP
> and SMTP because HTTP, FTP, SMTP clients (not protocol) will rely on DNS
> for hostname resolution and not viceversa.
I don't really think that make any difference. A protocol is a
protocol, whatever it depends on. The fact that you need a DNS
resolution when sending an Http request does not make DNS a
'different' protocol. Anyway, this is just a question of perception
...
>
> If a developer builds its own protocol to be used on internet, well, it
> is very likely to need DNS somewhere.
>
> That's why I think that DNS belongs to MINA TLP.
I don't see any connection between the fact that DNS is used by any
other services and the idea that DNS protocol should belongs to MINA
TLP...
I don't want to start a never ending discussion on this, so consider
that the fact we don't agree does not mean I'm right :)
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: DHCP Protocol Home (was: Re: [Vote] Sandboxing DHCP protocol)
Posted by Stefano Bagnara <ap...@bago.org>.
Trustin Lee ha scritto:
> You guys might think I am stupid, but I think both Emmanuel and
> Stefano are correct. It's a matter of point of view.
>
> The primary mission of MINA project is to provide an easy way to
> develop a network application. Today, many net apps are built with
> proprietary immature protocols because of lack of research and
> customizable protocol implementation. If we provide an out-of-the-box
> codec for HTTP, FTP, SMTP, and DNS, people will start to reuse
> existing standard protocol and overall interoperability in the
> industry will increase. (I hope!)
My opinion was very related to DNS. IMHO DNS is different from FPT, HTTP
and SMTP because HTTP, FTP, SMTP clients (not protocol) will rely on DNS
for hostname resolution and not viceversa.
If a developer builds its own protocol to be used on internet, well, it
is very likely to need DNS somewhere.
That's why I think that DNS belongs to MINA TLP.
About SMTP, FTP, HTTP and so on I see MINA only as an incubator,
specific to MINA based product.
As I said as MINA user I would probably expect to find DNS resolution
helpers directly in the core distribution of mina and not even as a
separate download: we cannot tell people you do everything
asynchronously but you will have your thread to wait X seconds for the
reverse lookup ;-)
Stefano
Re: DHCP Protocol Home (was: Re: [Vote] Sandboxing DHCP protocol)
Posted by Trustin Lee <tr...@gmail.com>.
You guys might think I am stupid, but I think both Emmanuel and
Stefano are correct. It's a matter of point of view.
The primary mission of MINA project is to provide an easy way to
develop a network application. Today, many net apps are built with
proprietary immature protocols because of lack of research and
customizable protocol implementation. If we provide an out-of-the-box
codec for HTTP, FTP, SMTP, and DNS, people will start to reuse
existing standard protocol and overall interoperability in the
industry will increase. (I hope!)
But it doesn't mean that MINA has to host all the protocol codec.
There are implementations for such protocols already. If they are
mature enough, MINA team will just provide a thin integration layer
for it and work closely with the authors of the protocol
implementation.
If there's no such implementation or it's not being maintained
actively, MINA team or other folks can create a new one. From this
standpoint, I think Apache Lab is the best place to start a new
protocol implementation. We can discuss again about where the project
should go later when it graduates the lab.
Someone could think that hosting the codec under MINA umbrella brings
a lot of benefit because MINA project would like to provide tooling
for protocol analyze and full-featured L7 switch which needs to
closely cooperate with protocol codec implementation. Other people
might think such a task can be done even if the codec implementation
doesn't belong to the MINA project. It's a very very controversial
issue. To be honest, I think it actually depends on how big project
MINA community can manage. For right now, we can't host all the
protocol implementations we want to integrate with.
We have too many things to fulfill to get to our ultimate mission yet,
so discussing about where it should go right now is not very
appropriate until a certain protocol implementation project cuts a
release IMHO.
Trustin
On 6/13/07, Emmanuel Lecharny <el...@gmail.com> wrote:
> Hi Stefano
>
> On 6/13/07, Stefano Bagnara <ap...@bago.org> wrote:
> > Emmanuel Lecharny ha scritto:
> > > DNS, DHCP, NTP are protocols but are also about storing data. There is
> > > nothing wrong in developping the protocol codec somwhere else, but I
> > > don't believe it should be MINA. For instance, AsyncWeb is now
> > > invcubating, because it was simply using MINA, and having under a MINA
> > > umbrella was just limitating its audience. MINA is supposed to be a
> > > network framework, if you start to aggregate all the protocols under
> > > its umbrella, I think you will soon have problems managing the
> > > project.
> >
> > A DNS client has nothing todo with storing data.
>
> Very true. This is something we have to think about : offering a
> client for each protocols. As I wrote this morning, I did had a lot of
> time to read all the mails, so my answer was based on what I read
> about writing another DNS server based on MINA.
>
> More to come in a few hours...
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
Re: DHCP Protocol Home (was: Re: [Vote] Sandboxing DHCP protocol)
Posted by Emmanuel Lecharny <el...@gmail.com>.
Hi Stefano
On 6/13/07, Stefano Bagnara <ap...@bago.org> wrote:
> Emmanuel Lecharny ha scritto:
> > DNS, DHCP, NTP are protocols but are also about storing data. There is
> > nothing wrong in developping the protocol codec somwhere else, but I
> > don't believe it should be MINA. For instance, AsyncWeb is now
> > invcubating, because it was simply using MINA, and having under a MINA
> > umbrella was just limitating its audience. MINA is supposed to be a
> > network framework, if you start to aggregate all the protocols under
> > its umbrella, I think you will soon have problems managing the
> > project.
>
> A DNS client has nothing todo with storing data.
Very true. This is something we have to think about : offering a
client for each protocols. As I wrote this morning, I did had a lot of
time to read all the mails, so my answer was based on what I read
about writing another DNS server based on MINA.
More to come in a few hours...
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: DHCP Protocol Home (was: Re: [Vote] Sandboxing DHCP protocol)
Posted by Stefano Bagnara <ap...@bago.org>.
Emmanuel Lecharny ha scritto:
> DNS, DHCP, NTP are protocols but are also about storing data. There is
> nothing wrong in developping the protocol codec somwhere else, but I
> don't believe it should be MINA. For instance, AsyncWeb is now
> invcubating, because it was simply using MINA, and having under a MINA
> umbrella was just limitating its audience. MINA is supposed to be a
> network framework, if you start to aggregate all the protocols under
> its umbrella, I think you will soon have problems managing the
> project.
A DNS client has nothing todo with storing data. It is like every other
protocol: it is needed to move information from a server that has the
data (and probably stores it) and a client that need the data (and
probably doesn't store it).
I think DNS lib belongs to MINA because MINA is a framework for internet
protocols: well, MANY internet protocols needs DNS lookups at the
beginning of the connection procedure.
Currently everyone is using synchronous lookups and this is not good for
a SEDA based protocol: so I think it is a *very* MINA specific task to
provide an asynchronous dns lookup facility to protocol writers.
My 2 cents,
Stefano
Re: DHCP Protocol Home (was: Re: [Vote] Sandboxing DHCP protocol)
Posted by Emmanuel Lecharny <el...@gmail.com>.
Hi, Trustin, Alex, and band,
I'm not available to comment a lot of what has been written (in an
hotel, being busy all day long while working for one of my client).
I will be short.
I do think thate there are 2 misconception done about the 'protocols'
we have under a Directory umbrella
1) We are not sandboxing because we don't believe in those protocols.
We are sandboxing because we have a non documented protocol, and this
is DHCP. It's a matter of time and committers
2) I saw another mail on MINA dev list, about DNS protocol being
written into MINA umbrella. In my mind, this would be just like
writing an B-Tree database in commons-collection, just because this
kind of DB is B-Tree based, a typical data structure. (I will comment
it later on MINA dev list)
DNS, DHCP, NTP are protocols but are also about storing data. There is
nothing wrong in developping the protocol codec somwhere else, but I
don't believe it should be MINA. For instance, AsyncWeb is now
invcubating, because it was simply using MINA, and having under a MINA
umbrella was just limitating its audience. MINA is supposed to be a
network framework, if you start to aggregate all the protocols under
its umbrella, I think you will soon have problems managing the
project.
Ok, I have to go, I hope I will find time tonite for more comments.
Emmanuel
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: DHCP Protocol Home (was: Re: [Vote] Sandboxing DHCP protocol)
Posted by Trustin Lee <tr...@gmail.com>.
Hi Alex,
On 6/12/07, Alex Karasulu <ak...@apache.org> wrote:
> Hi Trustin,
>
> On 6/12/07, Trustin Lee <tr...@gmail.com> wrote:
> >
> > Hi Alex,
> >
> > On 6/12/07, Alex Karasulu <ak...@apache.org> wrote:
> > > The question is not where DHCP will go. It's definitely slated for
> > > inclusion in ApacheDS to fullfil the Realm Controller concepts.
> > > So, this is not a matter of whether or not it deserves to be here at
> > > Directory. I don't want to turn this into that kind of discussion.
> > > This is just a matter of maturity and documentation I think.
> > >
> > > IMO MINA should not be the place to host all protocols. It can for
> > > some time host protocols specific projects that do not have critical
> > > community mass (like Asynchweb) until they blossom. But to try to
> > > build MINA out to be a massive TLP in this way is a big mistake and
> > > will result in the same issues that have confronted Jakarta. Keeping
> > >
> > the TLP lean and mean will keep it functional. I'd love tho to see
> > > protocol analyzers and other protocol development tooling sub-projects
> > > start at MINA tho.
> >
> > Well, DHCP can be used for other purposes, too.
>
>
> DHCP is for dynamic configuration whether used by network clients or
> by applications. It does not need t be used by just network hosts. However
> essentially it's usage is to access some configuration parameters that
> are centrally managed somewhere on the network. So I don't know what
> else besides configuration access it would be used for. Is there some other
> usage besides this and the basis for SLP that you're considering DHCP?
I meant accessing the configuration parameters can differ when one
wants to implement a specialized DHCPD. I am sorry for confusion.
> So, in the same
> > context, Directory project doesn't absolutely need to host it, either,
>
>
> No one absolutely needs to host it but at the present moment the best home
> it has is at Directory. I explain why below.
>
> The nature of this kind of data (configuration attributes) is relatively
> static yet
> shared across networks. Common shared information which is read more
> than it is written is idea for backing in LDAP. Plus LDAP can manage the
> constraints (syntax) on the information unlike a flat file. So as you can
> hopefully
> see LDAP is the ideal backing store. I cannot find better use case for
> storing this kind of information in any other store. LDAP is ideal for it.
>
> Furthermore ApacheDS is not just a Directory server. It's intended
> ultimately
> to be a replacement for Windows 2k+ servers in a single process. This is
> after
> all why me made protocols pluggable in MINA. It was one of the primary
> requirements
> so we could make other protocols like Kerberos snap in to yield a server
> that could do what a Windows server does today without all the moving parts.
I agree with you in that LDAP is a great place to store such
information and therefore it is reasonable to host related protocols
under Directory umbrella.
The problem we are confronting is that we have protocol
implementations that is not maintainable and we are sandboxing them.
We will have to keep building healthier community so we can revive
them someday in more a sustainable way.
<snip>
> I never believe MINA project team can adopt DHCP or other protocol
> > codecs right now because we are very busy enough working on various
> > transports and modifying the core. It will be quite far future when
> > we consider whether we provide many protocol codecs including
> > essential ones that boosts network application development (i.e. HTTP,
> > SMTP, FTP).
>
> If you notice my earlier post to the incubator list suggesting that FTP
> may find a good home in MINA. So it just depends on what can facilitate
> certain situations at different times. Hopefully community can build around
> everything but sometimes that takes serious time. Until then the best
> home is where the most synergy is at the moment. There are no absolutes
> in these matters: it's very fuzzy and we can at best align things that make
> sense one day but not forever.
Very true. That's why I am very cautious about adopting existing
protocol implementations under MINA umbrella. I'd cooperate with the
existing community so we can grow together rather than building our
own unsustainable realm.
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
Re: DHCP Protocol Home (was: Re: [Vote] Sandboxing DHCP protocol)
Posted by Alex Karasulu <ak...@apache.org>.
Hi Trustin,
On 6/12/07, Trustin Lee <tr...@gmail.com> wrote:
>
> Hi Alex,
>
> On 6/12/07, Alex Karasulu <ak...@apache.org> wrote:
> > The question is not where DHCP will go. It's definitely slated for
> > inclusion in ApacheDS to fullfil the Realm Controller concepts.
> > So, this is not a matter of whether or not it deserves to be here at
> > Directory. I don't want to turn this into that kind of discussion.
> > This is just a matter of maturity and documentation I think.
> >
> > IMO MINA should not be the place to host all protocols. It can for
> > some time host protocols specific projects that do not have critical
> > community mass (like Asynchweb) until they blossom. But to try to
> > build MINA out to be a massive TLP in this way is a big mistake and
> > will result in the same issues that have confronted Jakarta. Keeping
> >
> the TLP lean and mean will keep it functional. I'd love tho to see
> > protocol analyzers and other protocol development tooling sub-projects
> > start at MINA tho.
>
> Well, DHCP can be used for other purposes, too.
DHCP is for dynamic configuration whether used by network clients or
by applications. It does not need t be used by just network hosts. However
essentially it's usage is to access some configuration parameters that
are centrally managed somewhere on the network. So I don't know what
else besides configuration access it would be used for. Is there some other
usage besides this and the basis for SLP that you're considering DHCP?
So, in the same
> context, Directory project doesn't absolutely need to host it, either,
No one absolutely needs to host it but at the present moment the best home
it has is at Directory. I explain why below.
The nature of this kind of data (configuration attributes) is relatively
static yet
shared across networks. Common shared information which is read more
than it is written is idea for backing in LDAP. Plus LDAP can manage the
constraints (syntax) on the information unlike a flat file. So as you can
hopefully
see LDAP is the ideal backing store. I cannot find better use case for
storing this kind of information in any other store. LDAP is ideal for it.
Furthermore ApacheDS is not just a Directory server. It's intended
ultimately
to be a replacement for Windows 2k+ servers in a single process. This is
after
all why me made protocols pluggable in MINA. It was one of the primary
requirements
so we could make other protocols like Kerberos snap in to yield a server
that could do what a Windows server does today without all the moving parts.
because Directory project doesn't absolutely need to be the place to
> host all related protocol codecs such as DNS, DHCP, and Kerberos, and
> that's why we are sandboxing some protocols that we can't maintain.
> Of course, it never means that Directory project doesn't deserve to
> host those protocols; they are quite related with LDAP. It's a matter
> of point of view, and I understand your opinion and my opinion can be
> different.
Of course :).
I never believe MINA project team can adopt DHCP or other protocol
> codecs right now because we are very busy enough working on various
> transports and modifying the core. It will be quite far future when
> we consider whether we provide many protocol codecs including
> essential ones that boosts network application development (i.e. HTTP,
> SMTP, FTP).
If you notice my earlier post to the incubator list suggesting that FTP
may find a good home in MINA. So it just depends on what can facilitate
certain situations at different times. Hopefully community can build around
everything but sometimes that takes serious time. Until then the best
home is where the most synergy is at the moment. There are no absolutes
in these matters: it's very fuzzy and we can at best align things that make
sense one day but not forever.
Alex
Re: DHCP Protocol Home (was: Re: [Vote] Sandboxing DHCP protocol)
Posted by Alex Karasulu <ak...@apache.org>.
Hi Trustin,
On 6/12/07, Trustin Lee <tr...@gmail.com> wrote:
>
> Hi Alex,
>
> On 6/12/07, Alex Karasulu <ak...@apache.org> wrote:
> > The question is not where DHCP will go. It's definitely slated for
> > inclusion in ApacheDS to fullfil the Realm Controller concepts.
> > So, this is not a matter of whether or not it deserves to be here at
> > Directory. I don't want to turn this into that kind of discussion.
> > This is just a matter of maturity and documentation I think.
> >
> > IMO MINA should not be the place to host all protocols. It can for
> > some time host protocols specific projects that do not have critical
> > community mass (like Asynchweb) until they blossom. But to try to
> > build MINA out to be a massive TLP in this way is a big mistake and
> > will result in the same issues that have confronted Jakarta. Keeping
> >
> the TLP lean and mean will keep it functional. I'd love tho to see
> > protocol analyzers and other protocol development tooling sub-projects
> > start at MINA tho.
>
> Well, DHCP can be used for other purposes, too.
DHCP is for dynamic configuration whether used by network clients or
by applications. It does not need t be used by just network hosts. However
essentially it's usage is to access some configuration parameters that
are centrally managed somewhere on the network. So I don't know what
else besides configuration access it would be used for. Is there some other
usage besides this and the basis for SLP that you're considering DHCP?
So, in the same
> context, Directory project doesn't absolutely need to host it, either,
No one absolutely needs to host it but at the present moment the best home
it has is at Directory. I explain why below.
The nature of this kind of data (configuration attributes) is relatively
static yet
shared across networks. Common shared information which is read more
than it is written is idea for backing in LDAP. Plus LDAP can manage the
constraints (syntax) on the information unlike a flat file. So as you can
hopefully
see LDAP is the ideal backing store. I cannot find better use case for
storing this kind of information in any other store. LDAP is ideal for it.
Furthermore ApacheDS is not just a Directory server. It's intended
ultimately
to be a replacement for Windows 2k+ servers in a single process. This is
after
all why me made protocols pluggable in MINA. It was one of the primary
requirements
so we could make other protocols like Kerberos snap in to yield a server
that could do what a Windows server does today without all the moving parts.
because Directory project doesn't absolutely need to be the place to
> host all related protocol codecs such as DNS, DHCP, and Kerberos, and
> that's why we are sandboxing some protocols that we can't maintain.
> Of course, it never means that Directory project doesn't deserve to
> host those protocols; they are quite related with LDAP. It's a matter
> of point of view, and I understand your opinion and my opinion can be
> different.
Of course :).
I never believe MINA project team can adopt DHCP or other protocol
> codecs right now because we are very busy enough working on various
> transports and modifying the core. It will be quite far future when
> we consider whether we provide many protocol codecs including
> essential ones that boosts network application development (i.e. HTTP,
> SMTP, FTP).
If you notice my earlier post to the incubator list suggesting that FTP
may find a good home in MINA. So it just depends on what can facilitate
certain situations at different times. Hopefully community can build around
everything but sometimes that takes serious time. Until then the best
home is where the most synergy is at the moment. There are no absolutes
in these matters: it's very fuzzy and we can at best align things that make
sense one day but not forever.
Alex
Re: DHCP Protocol Home (was: Re: [Vote] Sandboxing DHCP protocol)
Posted by Trustin Lee <tr...@gmail.com>.
Hi Alex,
On 6/12/07, Alex Karasulu <ak...@apache.org> wrote:
> The question is not where DHCP will go. It's definitely slated for
> inclusion in ApacheDS to fullfil the Realm Controller concepts.
> So, this is not a matter of whether or not it deserves to be here at
> Directory. I don't want to turn this into that kind of discussion.
> This is just a matter of maturity and documentation I think.
>
> IMO MINA should not be the place to host all protocols. It can for
> some time host protocols specific projects that do not have critical
> community mass (like Asynchweb) until they blossom. But to try to
> build MINA out to be a massive TLP in this way is a big mistake and
> will result in the same issues that have confronted Jakarta. Keeping
>
the TLP lean and mean will keep it functional. I'd love tho to see
> protocol analyzers and other protocol development tooling sub-projects
> start at MINA tho.
Well, DHCP can be used for other purposes, too. So, in the same
context, Directory project doesn't absolutely need to host it, either,
because Directory project doesn't absolutely need to be the place to
host all related protocol codecs such as DNS, DHCP, and Kerberos, and
that's why we are sandboxing some protocols that we can't maintain.
Of course, it never means that Directory project doesn't deserve to
host those protocols; they are quite related with LDAP. It's a matter
of point of view, and I understand your opinion and my opinion can be
different.
I never believe MINA project team can adopt DHCP or other protocol
codecs right now because we are very busy enough working on various
transports and modifying the core. It will be quite far future when
we consider whether we provide many protocol codecs including
essential ones that boosts network application development (i.e. HTTP,
SMTP, FTP). But I also think providing a codec for less popular
protocols such as DNS will be beneficial for those who want to build a
light weight name service.
Moreover, we will do our best to implement such a codec in joint with
existing project team (or author) such as dnsjava. For example, we
could reuse dnsjava's DNS message model and encoding/decoding code,
and provide its simple wrapper for MINA, which is a very thin
integration layer. As for AsyncWeb, I agree with you, and the same
approach can be applied to it too like we are going to do with DNS
once it goes TLP since its growth.
However, if there's no Java protocol codec implementation and MINA
needs to provide integration with the protocol, MINA team could
provide the codec if there are *enough* people who are interested in
it.
Actually, we really need to wait and see what's going on while we do
what we have to do for now because someone might appear someday and
say 'hey I implemented protocol XXX!', and then we don't need to worry
about hosting all protocols. :)
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
Re: DHCP Protocol Home (was: Re: [Vote] Sandboxing DHCP protocol)
Posted by Trustin Lee <tr...@gmail.com>.
Hi Alex,
On 6/12/07, Alex Karasulu <ak...@apache.org> wrote:
> The question is not where DHCP will go. It's definitely slated for
> inclusion in ApacheDS to fullfil the Realm Controller concepts.
> So, this is not a matter of whether or not it deserves to be here at
> Directory. I don't want to turn this into that kind of discussion.
> This is just a matter of maturity and documentation I think.
>
> IMO MINA should not be the place to host all protocols. It can for
> some time host protocols specific projects that do not have critical
> community mass (like Asynchweb) until they blossom. But to try to
> build MINA out to be a massive TLP in this way is a big mistake and
> will result in the same issues that have confronted Jakarta. Keeping
>
the TLP lean and mean will keep it functional. I'd love tho to see
> protocol analyzers and other protocol development tooling sub-projects
> start at MINA tho.
Well, DHCP can be used for other purposes, too. So, in the same
context, Directory project doesn't absolutely need to host it, either,
because Directory project doesn't absolutely need to be the place to
host all related protocol codecs such as DNS, DHCP, and Kerberos, and
that's why we are sandboxing some protocols that we can't maintain.
Of course, it never means that Directory project doesn't deserve to
host those protocols; they are quite related with LDAP. It's a matter
of point of view, and I understand your opinion and my opinion can be
different.
I never believe MINA project team can adopt DHCP or other protocol
codecs right now because we are very busy enough working on various
transports and modifying the core. It will be quite far future when
we consider whether we provide many protocol codecs including
essential ones that boosts network application development (i.e. HTTP,
SMTP, FTP). But I also think providing a codec for less popular
protocols such as DNS will be beneficial for those who want to build a
light weight name service.
Moreover, we will do our best to implement such a codec in joint with
existing project team (or author) such as dnsjava. For example, we
could reuse dnsjava's DNS message model and encoding/decoding code,
and provide its simple wrapper for MINA, which is a very thin
integration layer. As for AsyncWeb, I agree with you, and the same
approach can be applied to it too like we are going to do with DNS
once it goes TLP since its growth.
However, if there's no Java protocol codec implementation and MINA
needs to provide integration with the protocol, MINA team could
provide the codec if there are *enough* people who are interested in
it.
Actually, we really need to wait and see what's going on while we do
what we have to do for now because someone might appear someday and
say 'hey I implemented protocol XXX!', and then we don't need to worry
about hosting all protocols. :)
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6