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
