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
