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
