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
